On Wed, Feb 24, 2021 at 01:13:37PM -0800, Darrick J. Wong wrote: > On Tue, Feb 23, 2021 at 07:05:03PM +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Currently every journal IO is issued as REQ_PREFLUSH | REQ_FUA to > > guarantee the ordering requirements the journal has w.r.t. metadata > > writeback. THe two ordering constraints are: > > > > 1. we cannot overwrite metadata in the journal until we guarantee > > that the dirty metadata has been written back in place and is > > stable. > > > > 2. we cannot write back dirty metadata until it has been written to > > the journal and guaranteed to be stable (and hence recoverable) in > > the journal. > > > > The ordering guarantees of #1 are provided by REQ_PREFLUSH. This > > causes the journal IO to issue a cache flush and wait for it to > > complete before issuing the write IO to the journal. Hence all > > completed metadata IO is guaranteed to be stable before the journal > > overwrites the old metadata. > > > > The ordering guarantees of #2 are provided by the REQ_FUA, which > > ensures the journal writes do not complete until they are on stable > > storage. Hence by the time the last journal IO in a checkpoint > > completes, we know that the entire checkpoint is on stable storage > > and we can unpin the dirty metadata and allow it to be written back. .... > If I've gotten this right so far, patch 4 introduces the ability to > flush the data device while we get ready to overwrite parts of the log. Yes. > This patch makes it so that writing a commit (or unmount) record to an > iclog causes that iclog write to be issued (to the log device) with at > least FUA set, and possibly PREFLUSH if we've written out more than one > iclog since the last commit? Yes. > IOWs, the data device flush is now asynchronous with CIL processing and > we've ripped out all the cache flushes and FUA writes for iclogs except > for the last one in a chain, which should maintain data integrity > requirements 1 and 2? Yes. > If that's correct, > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> Thanks! Dave. -- Dave Chinner david@xxxxxxxxxxxxx
