On Oct 19, 2010, at 2:21 PM, Xin LI wrote:

quoted text
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 10/19/10 08:49, Marcel Moolenaar wrote:
>> 
>> On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote:
>> 
>>> On 19.10.2010 09:03, Andrey V. Elsukov wrote:
>>>>> 	Mounting from (...) failed with error 19
>>>>> 
>>>>> On boot.  The system is using pure ZFS setup.  It seems that 19 means
>>>>> ENODEV but according to the dmesg the device do exist.
>>>> 
>>>> Yes, i have the same problem.
>>> 
>>> I fixed it with attached patch.
>> 
>> Makes sense. "tank" (or its namesake) isn't a real device.
>> Feel free to commit to unbreak things, but we may want to
>> rethink this from a generality point of view. Listing
>> exceptions doesn't scale and we now have 2 (the first was
>> the empty device name as used by nfs, and now also zfs).
>> 
>> Good catch, BTW.
> 
> Yes good catch, it fixed the problem for me as well.
> 
> What about the attached patch?  I'm going to give it a swirl soon.  The
> difference is that it tests whether dev begins with /dev/.

Interesting. I've been thinking about this too, but isn't
exactly fool-proof. When devfs is the root file system,
you can use "ufs:da0s1a" to refer to the device special
file. It seems inconsistent to have "ufs:da0s1" fail when
ufs:/dev/da0s1" works (a real scenario with USB based mass
storage devices -- root mount is unheld as soon as umass
is created, but before daX exists for it).

This patch at least covers the problem cases with a single
strstr(), and we may get away with the inconsistency given
above by documenting it properly.

Andrey: any thoughts?

-- 
Marcel Moolenaar
xcllnt@mac.com



_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"