Re: XFS and write barriers.

[David Chinner <dgc@sgi.com>]

On Mon, Mar 26, 2007 at 10:01:01AM +1000, Neil Brown wrote:
> On Sunday March 25, dgc@sgi.com wrote:
> > On Fri, Mar 23, 2007 at 07:00:46PM +1100, Neil Brown wrote:
> > > 
> > > Why no barriers on an external log device??? Not important, just
> > > curious.
> > 
> > because we need to synchronize across 2 devices, not one, so issuing
> > barriers on an external log device does nothing to order the metadata
> > written to the other device...
> 
> Right, of course.  Just like over a raid0.
> 
> So you must have code to wait for all writes to the main device before
> writing the commit block on the journal.

Forget about what you know about journalling from ext3, XFS is
vastly different and much more complex..... ;)

We wait for space in the log to become available during transaction
reservation; we don't wait for specific I/Os to complete because we
just push a bunch out. Once we have a reservation, we know we have
space in the log for our transaction commit and so we don't have to
wait for any I/O to complete when we do our transaction commit.
Hence we don't wait for the I/Os we may have issued to make space
available; another thread's push may have made enough space for our
reservation. IOWs, we've got *no idea* what the dependent I/Os are
when writing the transaction commit to disk because we have no clue
as to what we are overwriting in the journal.

This journalling method assumes that we either have no drive level
caching, non-volatile caching, or barrier-based log I/Os to prevent
corruption on drive power loss.  Hence with external logs on XFS
you have the option of no caching or non-volatile caching....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group