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
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.
Cheers,
Stephen
_______________________________________________
Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users
