finding out whether a device supports ordered writes ahead of time

finding out whether a device supports ordered writes ahead of time

[Christoph Hellwig]

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?

Re: finding out whether a device supports ordered writes ahead of time

[Chris Mason]

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