Date: Wed, 10 Dec 2008 02:32:24 -0500 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Ed Schouten <ed@80386.nl>, arch@FreeBSD.org Subject: Re: RFC: New VOP to translate vnode to its component name Message-ID: <1228894344.35477.40.camel@shumai.marcuscom.com> In-Reply-To: <alpine.BSF.1.10.0812091120380.34663@fledge.watson.org> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <e7db6d980812071143x4d395c7bt3f871e95430efc94@mail.gmail.com> <alpine.BSF.1.10.0812081805120.91087@fledge.watson.org> <1228784805.69132.66.camel@shumai.marcuscom.com> <alpine.BSF.1.10.0812091120380.34663@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-4kroQkURKgDuEQXfhAx6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote: > On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: >=20 > >> Just to give a general vote of "we need to do something here, whether = the=20 > >> details are exactly these or not" -- having better object->path resolu= tion=20 > >> is quite important for audit, as well as if we want to adopt a file sy= stem=20 > >> notification services along the lines of Apple's fsevents (which is=20 > >> path-centric and operates from close() events rather than open() event= s).=20 > >> I don't think we should run in the Linux 'dentry' direction, but havin= g a=20 > >> more robust translation service would be quite valuable. One comment:= I=20 > >> think we should continue to have a KPI which does a sleep-free transla= tion=20 > >> to call, but with weaker semantics than one that is sleepable and can = query=20 > >> for more robust reverse lookup. > > > > Okay, what about a name? >=20 > Oh, I do love a good bikeshed. I'm actually fine with any of these, but=20 > vn_fullpath_cache() sounds good to me. One of the cases I have in mind i= s=20 > path-based MAC policies, which will convert from a vnode to a path while=20 > holding the vnode lock -- if something is going to run around locking vno= des=20 > and doing VOP_READDIR's, that is not the time to do it. I've duplicated vn_fullpath, vn_fullpath_global, and textvp_fullpath in this latest version. The new (well, old) functions are named *_cache. I even updated the vn_fullpath.9 man page. http://www.marcuscom.com/downloads/vop_vptocnp_7.diff Joe >=20 > Robert N M Watson > Computer Laboratory > University of Cambridge >=20 > > > > vn_fullpath_cache > > vn_fullpath_quick > > vn_fullpath_fast > > vn_fullpath_nosleep > > ... > > > > Joe > > > >> > >> Robert N M Watson > >> Computer Laboratory > >> University of Cambridge > >> > >>> > >>> Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of > >>> works, but it quickly becomes unusable if any paths involve NFS. nfs > >>> times out its cached items very quickly. > >>> > >>> Anyway, I see this as a good first step. I very much want to see a > >>> real vop_default implementation that does the readdir("..") method to > >>> fill in the gaps. It isn't particularly important to me if > >>> vn_fullpath() recovers the original pathname or not, so long as it ca= n > >>> find *a* valid pathname that will work. > >>> > >>> As for names.. VOP_CNP doesn't tell me what it does at a glance. Ide= as: > >>> VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) > >>> VOP_RLOOKUP (reverse lookup) > >>> > >>> We have precedent for the first form. VOP_FHTOVP(). > >>> > >>> I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a > >>> little more intuitive to a casual observer. I don't want to get > >>> trapped in a bikeshed sized To:/CC: list over it though. I'd rather > >>> see it committed to head and get some progress. > >>> > >>> BTW: at work we do extensive open-by-filehandle stuff on NFS. For th= e > >>> vast majority of vnodes on those machines, there never was a name > >>> cache entry. It would be priceless if the vop_default readdir(..) > >>> method could discover those names in procstat etc. > >>> > >>> -- > >>> Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; = KI6FJV > >>> "All of this is for nothing if we don't go to the stars" - JMS/B5 > >>> "If Java had true garbage collection, most programs would delete > >>> themselves upon execution." -- Robert Sewell > >>> _______________________________________________ > >>> freebsd-arch@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch > >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.or= g" > >>> > >> > > --=20 > > Joe Marcus Clarke > > FreeBSD GNOME Team :: gnome@FreeBSD.org > > FreeNode / #freebsd-gnome > > http://www.FreeBSD.org/gnome > > >=20 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-4kroQkURKgDuEQXfhAx6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk/cIcACgkQb2iPiv4Uz4drigCcDwegRzzJi6D2R99oD+1WQG0+ XrwAn2uJzcpJVrqOHuCWY2fV5xXqfa6D =tXYQ -----END PGP SIGNATURE----- --=-4kroQkURKgDuEQXfhAx6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1228894344.35477.40.camel>