Re: Enable asynchronous commits by default patch revoked?

[Theodore Tso <tytso@mit.edu>]

On Mon, Aug 24, 2009 at 04:28:16PM -0400, Ric Wheeler wrote:
>
> My issue with the async commit is that it is basically a detection  
> mechanism.
>
> Drives will (almost always) write to platter sequential writes in order.  
> Async commit lets us send down things out of order which means that we  
> have a wider window of "bad state" for any given transaction...

Sure, agreed.  But let's look a bit closer at what "async commit"
really means.

What ext3 and ext4 does by default is this:

1)  Write data blocks required by data=ordered mode (if any)

2)  Write the journal blocks

3)  Wait for the journal blocks to be sent to disk.  (We don't actually
do a barrier operation), so this just means the blocks have been sent
to the disk, not necessarily that they are forced to a platter.

4)  Write the commit block, with the barrier flag set.

5)  Wait for the commit block.

-----

What the current async commit code does is this:

1)  Write data blocks required by data=ordered mode (if any)

2)  Write the journal blocks

3)  Write the commit block, without a barrier.

4)  Wait for the journal blocks to be sent to disk.

5)  Wait for the commit block (since a barrier is requested, this is
just when it was sent to the disk, not when it is actually committed
to stable store).

Since there are no barriers at all, the async mount option basically
works the same as barriers=0, and is subject to exactly the same
problems as barrier=0 --- problems which I've actually demonstrated
exist in practice.

----

What I think we can do safely in ext4 is this:

1)  Write data blocks required by data=ordered mode (if any)

2)  Write the journal blocks

3)  Write the commit block, WITH a barrier requested.

4)  Wait for the commit block to be completed.

5)  Wait for the journal blocks to be sent to disk.  #4 implies that
all of the journal block I/O will have been completed, so this is just
to collect the commit completion status; we should actually block
during step #5, assuming the block layer's barrier operation was
implemented correctly.


This should save us a little bit, since it implies the commit record
will be sent to disk in the same I/O request to the storage device as
the the other journal blocks, which is _not_ currently the case today.


Technically, what ext3 does today could result in problems, since
without the barrier between the journal blocks and the commit block,
the two could theoretically get reordered by the disk such that the
commit block is written before the journal blocks are completely
written --- and since ext3 doesn't have journal checksumming, this
would never be noticed.  Fortunately in practice this generally won't
happen since the commit block is adjacent to the rest of the journal
blocks, so a sane disk drive will likely coalesce the two write
requests together.

						- Ted