Date: Fri, 26 Nov 1999 16:16:18 +0100 From: Eivind Eklund <eivind@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: ezk@cs.columbia.edu, fs@FreeBSD.ORG Subject: Re: namei() and freeing componentnames Message-ID: <19991126161618.B44210@bitbox.follo.net> In-Reply-To: <199911241855.LAA21738@usr08.primenet.com>; from tlambert@primenet.com on Wed, Nov 24, 1999 at 06:55:04PM %2B0000 References: <19991118153220.E45524@bitbox.follo.net> <199911241855.LAA21738@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 24, 1999 at 06:55:04PM +0000, Terry Lambert wrote: > > Yes, this is the intent. > > > > The problem I'm finding with VOP_RELEASEND() is that namei() can > > return two different vps - the dvp (directory vp) and the actual vp > > (inside the directory dvp points at), and that neither of these are > > always available. > > What gets returned is based on the flags passed down. I think > that trying to encapsulate this transparently, so that any > namei() operation that succeeds or fails can be freed in its > entirety without resort to flags specific code in the caller > is a mistake. I don't think you can reasonably do this. What it presently frees is only the patch component buffeer. > One issue that occurs to me is that namei() itself, and not the > underlying VOP_LOOKUP code, should be the one to reference the > path component name cache. If the underlying VFS doesn't want > the cache hit to occur without notifying it of the event, then > it needs to not enter the data in the cache. This would simplify > a large amount of code. Where? How? I do not quite get this - could you give a few more details or pointers to some code it would modify? > The other simplification, which is organizational, and could, > using inline functions, be effectively NULL additional code > overhead, is to seperate the lookup operations by request > type. Whether or not something wants the parent directory > back has much to do with whther it is a create or rename > operation, and little to do with anything else. Operations > which intend to modify the returned directory entry are very > distinct from those merely doing a lookup. I have thought of it, and have been very tempted to do it. I've not yet tried to find out how much code impact it would have; there are a few namei()'s that are at a different layer than the NDINIT()s, and I've chosen to do the frees at the same layer as the NDINIT() - as that is where how the allocation is done is decided (as namei() is dependent on the flags). > I have often felt that much of the mess create/rename/delete/open > variant behaviour causes should be addressed by moving the > complexity to upper level code. I tend to agree, but I am not certain how easy it will be, nor whether it will end up really clean - I may look at this once I've done the other cleanups. I feel it as less important than the rest. [On changing the detailedness of lock specifications in vnode_if.src, in order to be able to generate proper lock assertions] > Please keep an eye towards not precluding Jermey Allisons work > on a kernel opportunity locking interface, since it's really > needed to do hosted OS/host OS coherency properly (e.g. Samba > clients must obey UNIX locks, and UNIX applications must obey > those of Samba). This is similar to what NFS clients and local > applications must do to interoperate, and is the primary purpose > of the LOASE interface. I must admit to not understanding the lease interface at all. I do not think any of the work I am doing at the moment will impact it; I only deal with vnode locks. > > (2) Change the behaviour of VOP_LOOKUP() to "eat as much as you can, > > and return how much that was" rather than "Eat a single path > > component; we have already decided what this is." > > This allows different types of namespaces, and it allows > > optimizations in VOP_LOOKUP() when several steps in the traversal > > is inside a single filesystem (and hey - who mounts a > > new filesystem on every directory they see, anyway?) > > The path component buffer mechanism already specifies this behaviour > as one of its initial design requirements, so I think this is already > taken care of. > > What does not happen is that lookups that will take place in a > single VFS are not held down in that VFS for the entire traversal, > but instead pop up to namei(). This was what I wanted to get rid of. > I don't think you can get rid of this, without destroying the > "union" option (not the same as the "unionfs"), and without > damaging the ability to cover mount points and to chroot or > do symlink expansion, or deal with POSIX namespace escape. I wanted to do it in order to be able to deal with POSIX namespace escapes, as the logic for how to handle the namespace would be pushed downwards, but I might not have thought all the implications through. I'll admit to working "pseudo-blind" - I do not understand all details and architecture of the code, and try to understand detail by detail as I need to in order to bring things forward. > One "low hanging fruit" optimization that can be made is to > _always_ set the fdp->fd_rdir to the processes current > root directory; this avoids the NULL/non-NULL test, so long > as it is inherited correctly on fork, and set for init. > > This would be very nice for many other reasons... 8-). That's the patches that are on your home page on freefall, right? I've been planning to commit them, I've just not gotten around to it. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991126161618.B44210>