From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 11:22:30 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74E61065676; Tue, 9 Dec 2008 11:22:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7680E8FC08; Tue, 9 Dec 2008 11:22:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 11D5046B38; Tue, 9 Dec 2008 06:22:30 -0500 (EST) Date: Tue, 9 Dec 2008 11:22:29 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Joe Marcus Clarke In-Reply-To: <1228784805.69132.66.camel@shumai.marcuscom.com> Message-ID: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <1228784805.69132.66.camel@shumai.marcuscom.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Ed Schouten , arch@FreeBSD.org Subject: Re: RFC: New VOP to translate vnode to its component name X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 11:22:30 -0000 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@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.org" >>> >> > -- > Joe Marcus Clarke > FreeBSD GNOME Team :: gnome@FreeBSD.org > FreeNode / #freebsd-gnome > http://www.FreeBSD.org/gnome >