Date: Wed, 22 Oct 1997 02:03:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! Message-ID: <199710220203.TAA09608@usr03.primenet.com> In-Reply-To: <19971021203807.51847@keltia.freenix.fr> from "Ollivier Robert" at Oct 21, 97 08:38:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Whatever needs to be done should probably be done in null_inactive(), > > look at sys/ufs/ufs/ufs_inode.c:ufs_inactive(). > > By using the following patch, I've been able to create and delete hundreds > of files in a nullfs mounted directory. No vnode leak as far as I can see > from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, > just works. Now that seems too easy :-) > > I know there is a comment in null_inactive() about doing nothing in there > but it seemed logical to inform the lower layer... > > PS: a similar problem is in umapfs which is based on nullfs. > > Opinions about this ? Using this approach sort of breaks the ability to collapse out intermediate vnode layers, since it leaves things associated with the upper level vnodes that probably ought not to be left associated. Specifically, if you look back to John's comment about vnode_pager_uncache, and then look at nullfs... Probably the "correct" way to handle this is to avoid aliases, and instead establish a null_getpage/null_putpage VOP for page access, and force it to make the reference to the underlying FS. This is actually a lot cleaner than implementing vp dereferencing ops, since it would allow you to pass the vp to the underlying FS back up in place of the vp for the covering fs. When you could do this really depends on if it's file ops, directory ops, or whatever. For example, if an open returns an alias node, then the alias dereference needs to take place on anything which could reference it. But this does not necessarily mean both files and directories would be affected. One could easily envision a UID FS that only operated on files... The main problem is the page references, and the need for the vnode pager to be able to identify the pages referenced by the underlying vnode and those referenced by the upper level vnode, but which came from the lower level vnode. Similarly, you could envision a name space extension for resource forks which would stack and have file references turn into directories, and the actual file contents go into the "default" for defined as "name/data" instead of "name". Such an extension would return the underlying vnode for the "data" for, but an alias vnode for non-"data" fork. Really, I'd like to see per FS page routines, and things like the per fs inactive left actually NULL, where possible. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710220203.TAA09608>