Re: [Ext2-devel] Re: [RFC/RFT] [PATCH] EXT3: Retry allocation after journal commit

From: Andreas Dilger
Date: Fri May 14 2004 - 16:07:14 EST

On May 14, 2004 15:59 -0400, Theodore Ts'o wrote:
> On Fri, May 14, 2004 at 11:48:37AM -0600, Andreas Dilger wrote:
> > Well, actually my patch just waited on the _previous_ transaction to commit
> > (which can be done anywhere without retrying the operation) and then set
> > h_sync on the _current_ transaction so that as soon as the current operations
> > are completed it will also be committed and the blocks released. One can't
> > of course arbitrarily call journal_stop() or that breaks the transaction
> > atomicity.
> >
> > For 99.9% of cases this should be sufficient and doesn't involve changing
> > the code everywhere - only in ext3_new_block().
> I tried that first, actually. In the test case I was trying, it only
> worked 33% of the time. The other 66% of the time, the rm -rf all fit
> into the current running transaction, and waiting on the previous
> transaction wasn't sufficient to solve the problem.

I guess the success ratio dependends on how many blocks are tied up in
the transaction, the size of the journal, and how much free space is
left in the filesystem. In my tests (dd to a file that does O_TRUNC and
overwrites with the same file size) this change wasn't 100% successful
but fixed it the majority of the time.

> > Also, Ted's approach of retrying the operations "outside" the
> > transaction won't work if there are nested journal transactions
> > being done - those will hold the transaction open so doing
> > journal_stop/journal_start doesn't really accomplish anything.
> That was why I was retrying at the top-level functions: ext3_mkdir,
> for example. There won't be a nested journal transaction there.

Waiting for the currently committing transaction to complete would
deadlock Lustre, because it starts journal transactions above ext3 so
that it can write update records in the same transaction as the
filesystem operation.

Cheers, Andreas
Andreas Dilger

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at