Re: CVS commit: src/sys/fs/tmpfs

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Fri Apr 10 2009 at 22:36:38 +0000, Andrew Doran wrote:
> On Sat, Apr 11, 2009 at 01:32:09AM +0300, Antti Kantee wrote:
> 
> > On Fri Apr 10 2009 at 21:34:10 +0000, Andrew Doran wrote:
> > > On Fri, Apr 10, 2009 at 06:57:45PM +0200, Frank Kardel wrote:
> > > 
> > > > It may be related: I am now seeing a tmpfs uvm_fault():
> > > > 
> > > > hand copied bt:
> > > > uvm_fault()
> > > > tmpfs_do_detach()
> > > > tmpfs_remove()
> > > > VOP_REMOVE()
> > > > do_sys_unlink()
> > > > syscall()
> > > 
> > > It may be this: http://gnats.netbsd.org/41183
> > 
> > Might be.  I filed a PR for that ages ago and had forgotten all about
> > it by now.  See kern/38188.
> 
> On the face of it what do you think of:
> 
> - preserve pnbuf across entirety of operations that use it
> - retire SAVENAME, VOP_ABORTOP()
> - encapsulate operations with namei_init(), fini() or whatnot.

I thought the general agreement was to move to deferring final lookup
until the actual operation.

I don't see the difference between namei_fini() and ABORTOP, although
maybe the first is more explicit and less confusing for people not
familiar with vfs.

> - copy pathname to persistent storage where required (NFS?)

Or make pnbuf an object with a reference counter?  But is that optimizing
for the worst case?

The two questions I'm always too tired to answer to myself are:
1) how does this work with nfs(d)
2) how does this work with layered file systems
   (ok, i peeked at unionfs.  unionfs has a creative abortop...  *punt*)