This mail is about an issue that has been of concern to me for quite a
while and I think it is (well past) time to air it more widely and try
to come to a resolution.
This issue is how write barriers (the block-device kind, not the
memory-barrier kind) should be handled by the various layers.
On Fri, May 25, 2007 at 12:43:51AM -0500, Alberto Alonso wrote:
The difference between ext3 and XFS is that ext3 will remount to
read-only on the first write error but the XFS won't, XFS only fails
only the current operation, IMHO. The method of ext3 isn't perfect, but
in practice,
On Fri, May 25, 2007 at 05:58:25PM +1000, Neil Brown wrote:
We can think of there being three types of devices:
1/ SAFE. With a SAFE device, there is no write-behind cache, or if
there is it is non-volatile. Once a write completes it is
completely safe. Such a device
On Fri, May 25 2007, David Chinner wrote:
The second, while much easier, can fail.
So we do a test I/O to see if the device supports them before
enabling that mode. But, as we've recently discovered, this is not
sufficient to detect *correctly functioning* barrier support.
Right, those
2007/5/25, Neil Brown [EMAIL PROTECTED]:
HOW DO MD or DM USE THIS
1/ striping devices.
This includes md/raid0 md/linear dm-linear dm-stripe and probably
others.
These devices can easily support blkdev_issue_flush by simply
calling blkdev_issue_flush on
On Friday 25 May 2007 06:55:00 David Chinner wrote:
Oh, did you look at your logs and find that XFS had spammed them
about writes that were failing?
The first message after the incident:
May 24 01:53:50 hq kernel: Filesystem loop1: XFS internal error
xfs_btree_check_sblock at line 336 of
Jens Axboe wrote:
A barrier write will include a flush, but it may also use the FUA bit to
ensure data is on platter. So the only situation where a fallback from a
barrier to flush would be valid, is if the device lied and told you it
could do FUA but it could not and that is the reason why the
Neil Brown wrote:
There is no guarantee that a device can support BIO_RW_BARRIER - it is
always possible that a request will fail with EOPNOTSUPP.
Why is it not the job of the block layer to translate for broken devices
and send them a flush/write/flush?
These devices would find it very
