Stephen C. Tweedie writes: > Hi, > > On Thu, Sep 26, 2002 at 03:36:49PM +0400, Nikita Danilov wrote: > > > > Can't do that. ext3 is fundamentally incapable of nesting activations > > > > But, parent activation here can well be reiser4, XFS, or ext3 on the > > different mount. > > That doesn't matter, all ext3 needs to know is "is the current > activation the one for the filesystem I'm already on?" If it's not, > it backs out. > > > How ext3 will get to the topmost handle to update its refcount if there > > is reiser4 activation in between? > > It doesn't --- it does the noop-writepage stuff I described if we're > recursing, to avoid reentering anywhere. > > The ext3 recursion code is there to let us detect the difference > between legitimate recursions and "incidental" ones inflicted on us by > the VM. > > It is simply not possible to allow recursion between different > filesystems in general. If you do, then the nested fs call may block > waiting for a commit on the other filesystem, so that the operation > running in the parent can't complete until the nested fs commits. > However, if that happens in both directions at once in different > tasks, you get a deadlock where neither filesystem can commit until > the other one has done so. This even happens between two > concurrently-running ext3 filesystems if you get things wrong; > "different" doesn't have to mean that it's a different _type_ of > filesystem. > > Now, there are special cases that you can allow to succeed if you're > careful, but you just cannot rely on those special cases being > applicable in all cases. If the filesystem can determine that it can > find enough reservations in the existing running transaction to > satisfy the nested operation without waiting for any transaction > commits, and if there are no synchronous operations involved which > would require a commit, then it may be possible to satisfy the nested > request. But if those conditions are not satisfied, then you *cannot* > safely recurse. I see. Probably we don't want generic distributed deadlock detection manager in the kernel, for now. :) > > And even when you do recurse, the filesystem can preserve the parent > activation reference in its own local storage. It can even put it on > the stack if it wants. There's no need for a pointer for that in the > generic activation object. Saving and restoring original parent activation reference is the protocol each file system has to obey, so putting pointer to parent in the generic object has some sense. I will be happy either way though. > > Cheers, > Stephen Nikita. _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
