2005-05-16 11:27:37

by Christoph Hellwig

[permalink] [raw]
Subject: finding out whether a device supports ordered writes ahead of time

Currently ext3 and reiserfs submit bios with BIO_RW_BARRIER and when the
device doesn't support it it returns EOPNOTUPP. This scheme doesn't
work at all for XFS because our I/O submission path keeps around far too
much state (XFS supports multi-page metadata buffers). From looking at
the code it seems that we can assume such a submission will just work
if q->ordered is not QUEUE_ORDERED_NONE. Is that a valid assumption?
and if yes should we look directly at the queue or provide an assecor?


2005-05-16 12:12:30

by Chris Mason

[permalink] [raw]
Subject: Re: finding out whether a device supports ordered writes ahead of time

On Monday 16 May 2005 07:27, Christoph Hellwig wrote:
> Currently ext3 and reiserfs submit bios with BIO_RW_BARRIER and when the
> device doesn't support it it returns EOPNOTUPP. This scheme doesn't
> work at all for XFS because our I/O submission path keeps around far too
> much state (XFS supports multi-page metadata buffers). From looking at
> the code it seems that we can assume such a submission will just work
> if q->ordered is not QUEUE_ORDERED_NONE. Is that a valid assumption?
> and if yes should we look directly at the queue or provide an assecor?

I think Jens currently has things set to trust the drive's advertisement of
the cache flush feature. But I don't think we've looked hard for drives that
advertise and then fail the barriers, it wouldn't surprise me if one existed.

What you could do is issue a barrier write during mount to test things. If
that works any failed barrier later could be considered an io error. Don't
use blkdev_issue_flush for this, since it will work on scsi drives that don't
support the BIO_RW_BARRIER.

-chris