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

Re: ->journal_info sharing


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.


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