On Fri, Jul 10, 2015 at 03:10:44PM +1000, NeilBrown wrote:

On Thu, 9 Jul 2015 21:52:43 -0700 Shaohua Li [off-list ref] wrote:

quoted

On Fri, Jul 10, 2015 at 02:36:56PM +1000, NeilBrown wrote:

quoted

On Thu, 9 Jul 2015 21:08:49 -0700 Shaohua Li [off-list ref] wrote:

quoted

quoted

There is also the issue of what action commits a previous transaction.
I'm not sure what you had.  I'm suggesting that each metadata block
commits previous transactions.  Is that a close-enough match to what
you had?

What did you mean about a transaction? In my implementation, metadata
block and followed stripe data/parity consist of an io unit. io units can
be finished out of order. but if io unit has flush request (the data has
flush/flush bio or metadata is a flush block), the io unit can only
start after all previous io units and disk cache flush finish. Such io
unit is strictly ordered. The log patch describes this behavior. Does it
match?

Yes, a "transaction" is an "io unit".  The flushing is the same.
I just couldn't remember how, when reading the log on restart, you
determined if a given "io unit" was reliably consistent, or whether it
should be ignored (having possibly only partially been written).

The metadata block has a checksum for data of the block. data/parity has
checksum stored in metadata block. This way we can know if metadata and
data is consistent.

Thanks,
Shaohua