Re: ordered I/O with multipath

[Jamie Lokier <jamie@shareable.org>]

谢纲 wrote:
> Some journal filesystem use barrier i/o to ensure the order of the
> committing data. But if the filesystem is on the top of volume manager
> which support the raid and multipath. The barrier i/o might not be
> handled correctly. How does journal filesystem deal with this?

For software RAID and multipath, I think it isn't handled at all.

Even if you disable write-caching in the underlying storage, ordered
requests may not retain their order, so the common database advice to
disable write-cache and use SCSI or SATA-NCQ may not work either.

If the RAID code is changed to handle barriers, that would still have
possible "scattershot" corruption on RAID-5, because writing a single
sector on the logical device affects more than one visible sector if
it is interrupted.  In other words, the "radius of corruption" is
bigger than one sector for RAID-5, and it's not contiguous either.

In principle, journalling filesystems need to know the "radius of
corruption" to provide robust journalling.  If individual sector
writes are atomic, this isn't an issue.  Some people think sector
writes are atomic on modern hard drives (but I wouldn't count on it).
But it is definitely not atomic when writing to a RAID or multipath if
the write affects more than one device.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html