Date: Mon, 08 Dec 2008 20:06:45 -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: <1228784805.69132.66.camel@shumai.marcuscom.com> In-Reply-To: <alpine.BSF.1.10.0812081805120.91087@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-AiGQsYX7/l7OWYkYDg0Q
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Mon, 2008-12-08 at 18:08 +0000, Robert Watson wrote:
> On Sun, 7 Dec 2008, Peter Wemm wrote:
>=20
> > Well, you already know I love the idea. Valgrind "knows" that you can=20
> > obtain the pathname from a fd or mmap address reliably at any time beca=
use=20
> > of procfs on linux, so its code is structured with that assumption.
>=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 resolutio=
n is=20
> quite important for audit, as well as if we want to adopt a file system=20
> notification services along the lines of Apple's fsevents (which is=20
> path-centric and operates from close() events rather than open() events).=
I=20
> don't think we should run in the Linux 'dentry' direction, but having a m=
ore=20
> robust translation service would be quite valuable. One comment: I think=
we=20
> should continue to have a KPI which does a sleep-free translation to call=
, but=20
> with weaker semantics than one that is sleepable and can query for more r=
obust=20
> reverse lookup.
Okay, what about a name?
vn_fullpath_cache
vn_fullpath_quick
vn_fullpath_fast
vn_fullpath_nosleep
...
Joe
>=20
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>=20
> >
> > 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 can
> > find *a* valid pathname that will work.
> >
> > As for names.. VOP_CNP doesn't tell me what it does at a glance. Ideas=
:
> > 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 the
> > 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.
> >
> > --=20
> > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI=
6FJV
> > "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.org"
> >
>=20
--=20
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
--=-AiGQsYX7/l7OWYkYDg0Q
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)
iEYEABECAAYFAkk9xKQACgkQb2iPiv4Uz4cc6ACdEyt3GfrgbK1WHn9K7XS9WTJS
PfwAn2HMmgU9j03VMCQTpq/J1Po7gw/+
=yXBP
-----END PGP SIGNATURE-----
--=-AiGQsYX7/l7OWYkYDg0Q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1228784805.69132.66.camel>