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

[Theodore Ts'o]

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.

> 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.  This
will be an issue for prepare_write(), though.  If we are in nested
transaction, we're going to have to wait for the currently committing
transaction, and hope for the best.  If that's not sufficient, we're
going to have return the ENOSPC failure.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/