Re: XFS and write barriers.

[Timothy Shimmin <tes@sgi.com>]

--On 25 March 2007 2:19:27 PM +1100 David Chinner <dgc@sgi.com> wrote:

> On Fri, Mar 23, 2007 at 07:00:46PM +1100, Neil Brown wrote:
>> On Friday March 23, tes@sgi.com wrote:
>> > >
>> > > I think this test should just be removed and the xfs_barrier_test
>> > > should be the main mechanism for seeing if barriers work.
>> > >
>> > Oh okay.
>> > This is all Christoph's (hch) code, so it would be good for him to comment here.
>> > The external log and readonly tests can stay though.
>> >
>>
>> 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...
>

I have wondered in the past (sgi-bug#954969) about doing a blk_issue_flush
on the metadata device at xlog_sync time prior to the log write on
the log device.

  27/July/06 - pv#954969
  Currently, if one uses external logs then the barrier support is turned off.
  The reaon for this is that a write barrier is normally only done on the data
  device which has the log.
  With an external log it means that a write barrier on a log device will not
  do any flushing on the metadata device.
  This pv is opened to explore the possibility of issuing an explicit metadata
  device flush at xlog_sync time before doing a write barrier on the log data
  to the log device.
  This would guarantee if the tail moved because a metadata thought its
  data was really on disk, would now be true as we would do a flush of
  its device. Then we could do our log write without worrying that
  our log write will overwrite log data when its metadata hadn't really made it.
  Perhaps I'm missing something.
  Dave (dgc) said he'd think about it.
  I haven't heard back from Christoph yet, and he added the
  code for our barrier support in xfs.
  --Tim

--Tim