Re: ->journal_info sharing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Cheers,
 Stephen



_______________________________________________

Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux