--On 25 March 2007 2:19:27 PM +1100 David Chinner <dgc@xxxxxxx> wrote:
On Fri, Mar 23, 2007 at 07:00:46PM +1100, Neil Brown wrote:
On Friday March 23, tes@xxxxxxx 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
|