[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/fs/tmpfs
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*)
Main Index |
Thread Index |