RFC: New VOP to translate vnode to its component name
Robert Watson
rwatson at FreeBSD.org
Tue Dec 9 03:22:30 PST 2008
On Mon, 8 Dec 2008, Joe Marcus Clarke wrote:
>> Just to give a general vote of "we need to do something here, whether the
>> details are exactly these or not" -- having better object->path resolution
>> is quite important for audit, as well as if we want to adopt a file system
>> notification services along the lines of Apple's fsevents (which is
>> path-centric and operates from close() events rather than open() events).
>> I don't think we should run in the Linux 'dentry' direction, but having a
>> more robust translation service would be quite valuable. One comment: I
>> think we should continue to have a KPI which does a sleep-free translation
>> to call, but with weaker semantics than one that is sleepable and can query
>> for more robust reverse lookup.
>
> Okay, what about a name?
Oh, I do love a good bikeshed. I'm actually fine with any of these, but
vn_fullpath_cache() sounds good to me. One of the cases I have in mind is
path-based MAC policies, which will convert from a vnode to a path while
holding the vnode lock -- if something is going to run around locking vnodes
and doing VOP_READDIR's, that is not the time to do it.
Robert N M Watson
Computer Laboratory
University of Cambridge
>
> 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 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.
>>>
>>> --
>>> Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>>>
>>
> --
> Joe Marcus Clarke
> FreeBSD GNOME Team :: gnome at FreeBSD.org
> FreeNode / #freebsd-gnome
> http://www.FreeBSD.org/gnome
>
More information about the freebsd-arch
mailing list