Re: [PATCH V4 00/13] MD: a caching layer for raid5/6

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

 



On Thu, 9 Jul 2015 21:52:43 -0700 Shaohua Li <shli@xxxxxx> wrote:

> On Fri, Jul 10, 2015 at 02:36:56PM +1000, NeilBrown wrote:
> > On Thu, 9 Jul 2015 21:08:49 -0700 Shaohua Li <shli@xxxxxx> wrote:
> > 

> > 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).

Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux