[ext3-users@redhat.com: CC me on replies, I am not subscribed.]
Stephen C. Tweedie writes:
> Hi,
>
> On Thu, Sep 26, 2002 at 03:07:52PM +0400, Nikita Danilov wrote:
>
> > > Well, the jbd layer is in theory usable in cases where there's no
> > > super_block (eg. a journaled soft raid5 layer), so a generic "void *
> > > owner" might be more appropriate. And having to allocate a new object
> > > each time makes little sense: for ext3, we already have lightweight
> > > per-task handles, so embedding the fs_activation in that would make
> > > more sense for me, and having a pointer to the parent in the
> > > activation object makes little sense if that object is already in the
> > > parent.
> >
> > Sorry for being vague, by "parent" I meant parent activation---previous
> > entrance into file system code, that called new one, rather than file
> > system specific object into which fs_activation is embedded.
>
> That's an internal detail of the filesystem, which doesn't have any
> relevance if you're just checking for an alien recursion.
>
> > No allocation is necessary, on the entry file system just does:
> >
> > foofs_enter(struct super_block *super, foofs_handle *handle)
> > {
> > handle->fs_activation.owner = super;
> > handle->fs_activation.parent = current->journal_info;
> > current->journal_info = &handle->fs_activation;
> > ...
> > }
>
> 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.
> like that, and I expect reiserfs is similar. The problem is that
> you've got finite log space, and sometimes you have to block waiting
> for existing transactions to commit before a new one can begin. For
> this reason, ext3 simply doesn't do recursive activations. However,
> it's got a mechanism for extending an existing activation if we get a
> recursion that we know we want to try, and in that case we just bump
> the refcount on the existing activation.
>
> In other words, where you are proposing chaining a list of
> activations, ext3 is using a refcount. In other words, it's a
> filesystem-internal implementation detail, and should not be part of
> the generic task_struct interface!
>
> > ->parent pointer is useful, for example, in
> >
> > ext3 -> reiser4 -> ext3
>
> Ext3 doesn't allow this, for the deadlock reasons outlined above. And
> you can't get multi-level recursions through the VM, else you'd
> overflow the stack: the task's PF_MEMALLOC flag gets set on entry to
> the VM, and once that's set you'll never get another recursion until
> the VM has finished its scan.
But it can be something like
write(ext3)->pagefault(reiser4 mmapped file)->VM(ext3),
or something like this.
How ext3 will get to the topmost handle to update its refcount if there
is reiser4 activation in between?
But in any case, file system has to restore ->journal_info to the
original state just before exiting. Having ->parent pointer in
fs_activation allows this to be done in the generic way.
>
> Cheers,
> Stephen
Nikita.
_______________________________________________
Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users
