Re: [Glibc-bsd-commits] r3162 - trunk/zfsutils/debian/patches
On Tue, Aug 24, 2010 at 03:06:26PM -0400, Tuco wrote:
> On 8/23/10, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >> This makes zpool import work. The real problem here is NOT that /dev/ is
> >> not searched for. On FreeBSD scan is usually performed by
> >> geom_find_import(), and /dev is not searched unless that fails. The
> >> problem was that GNU realpath() fails for inexistant paths and BSD
> >> realpath() doesn't.
> >>
> >
> > Given the explanation you are giving there, I am not sure it is the
> > correct fix. Given GNU realpath() behave differently than the BSD
> > realpath() used in the original code, how about fixing the code
> > that call realpath() to behave correctly with the GNU version?
>
> I'm sorry, this bug is a bit "weird", I will try to explain better.
> This is what original code in zpool is doing:
>
> 1. Resolve /dev/dsk/ using realpath(). If realpath() reports that
> /dev/dsk/ does not exist, it aborts here.
>
> 2. Access the device using GEOM, instead of /dev/ nodes. If this
> suceeds, it ends here. I think this part was added by FreeBSD.
>
> 3. If GEOM failed, use the resolved path from step 1 to access the
> device with open()/read()/etc.
>
> /dev/dsk/ doesn't exist on FreeBSD, it's a Solaris directory. However,
> this is harmless because BSD realpath() is buggy and reports that the
> path has been correctly resolved. Then GEOM does the real job, so they
> don't notice. However with GNU realpath() zpool aborts in step 1.
>
What worry me is that "/dev/dsk" is the default path, but the user can
specify another one through some options. Is it going to work in that
case? Also what happens if it fails opening the device through GEOM? Is
it safe?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: