Date: Sun, 14 Feb 2010 10:49:14 +0200 From: Jaakko Heinonen <jh@FreeBSD.org> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: Unable to pwd in ZFS snapshot Message-ID: <20100214084913.GA974@a91-153-117-195.elisa-laajakaista.fi> In-Reply-To: <20100214010526.GA11217@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> <20100214010526.GA11217@tops.skynet.lt>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 2010-02-14, Gleb Kurtsou wrote: > problem here lies in incorrect inode numbers (inconsistency between > VOP_READDIR and VOP_GETATTR). It's normal for mount points. This is problem for kernel vn_fullpath1()/vop_stdvptocnp() because ZFS clears VV_ROOT for snapshot root vnodes but I don't see this causing a problem in user space. > Fixing it only in kernel (__getcwd) doesn't necessarily fixes it for > all cases in userland, getcwd in our libc falls back to comparing > inode numbers User space getcwd() works just fine if the .zfs directory is visible (or am I missing something?). See the code in getcwd.c under comment "If it's a mount point, have to stat each element because the inode number in the directory is for the entry in the parent directory, not the inode number of the mounted file." User space getcwd() just can't work for hidden directories. > Fixing inode numbers would also fix pwd issues with namecache disabled. I don't think so. If the .zfs directory is hidden, vop_stdvptocnp() and user space getcwd() don't work. -- Jaakko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100214084913.GA974>