[zfs] Mounting from (...) failed with error 19
Marcel Moolenaar
xcllnt at mac.com
Tue Oct 19 22:49:09 UTC 2010
On Oct 19, 2010, at 2:21 PM, Xin LI wrote:
> -----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 at mac.com
More information about the freebsd-current
mailing list