Date: Tue, 10 Feb 2009 19:33:29 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Jaakko Heinonen <jh@saunalahti.fi> Cc: freebsd-fs@freebsd.org, Peter Jeremy <peter@vk2pj.dyndns.org>, Robert Watson <rwatson@freebsd.org> Subject: Re: Unable to pwd in ZFS snapshot Message-ID: <20090210173329.GA62256@deviant.kiev.zoral.com.ua> In-Reply-To: <20090210165204.GA4300@a91-153-125-115.elisa-laajakaista.fi> References: <20090207200918.GA58657@test71.vk2pj.dyndns.org> <20090209155521.GA3418@a91-153-125-115.elisa-laajakaista.fi> <alpine.BSF.2.00.0902091755210.7099@fledge.watson.org> <20090210165204.GA4300@a91-153-125-115.elisa-laajakaista.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
--EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 10, 2009 at 06:52:05PM +0200, Jaakko Heinonen wrote: >=20 > Hi, >=20 > On 2009-02-09, Robert Watson wrote: > > Now that we have a new VOP to assist in reverse-name resolution, it cou= ld be=20 > > that ZFS could provide the back-end lookup to address this issue withou= t=20 > > forcing the use of the namecache for things we don't want to cache. >=20 > I think that a bigger problem is how __getcwd() works. If single path > component lookup fails from cache or with VOP_VPTOCNP __getwcd() will > abort. So even if ZFS supported VOP_VPTOCNP perfectly some path > components may be on a file system which doesn't and the hidden ".zfs" > prevents userspace traversal from succeeding. >=20 > Actually ZFS caches the hidden ".zfs" directory (but nothing below it). > Thus if __getcwd() reverted to readdir scan only for those components > which really require it getcwd(3) should work right now (as long as > ".zfs" is in cache). >=20 > Looks like someone has tried to do this already: >=20 > http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027020.html >=20 > The patch doesn't apply against head anymore. It is being worked on right now. --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmRumkACgkQC3+MBN1Mb4hKawCfVwEd75djdbf6lbOn0adCDxRN Y4gAoOsS8xiXiA17ayoF5Oa2GaVpvaLE =PgRJ -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090210173329.GA62256>