>>>>> "Peter" == Peter Rabbitson <rabbit+list@xxxxxxxxx> writes: Peter> Bingo - and according to the list archive many of us are getting Peter> mismatches without swap anywhere near the raid in question. The Peter> current situation is more akin to "Ok folks get in the plane, Peter> we're deploying in 2 hours, and btw your chute is not going to Peter> open and there is nothing you can do about it" How is that for a Peter> threat model :) Way back we used to lock pages down entirely for I/O submission. At some point the writeback bit was introduced to gate the page during the actual (physical) write operation only. That made locking trickier and not all filesystems correctly adapted to this. ext[234] in particular have issues of varying degrees, somewhat amplified by their use of buffer_heads to track buffers instead of pages. See the recent thread about corruption with ext4 in 2.6.32+ for examples of this. It's not just RAID consistency that breaks. In the ext4 case above we end up with garbled blocks being written to a single drive. Add data integrity protection to the mix (btrfs, DIX) and all hell breaks loose if you change the buffer after the checksum has been generated. So while modifying pages in flight has kinda-sorta worked for a while (i.e. the window of error is small) it's something we'll simply have to stop doing to support new features in the storage stack. You'll be glad to know there's discussion about merging the debug patch (which marks pages read-only during writeback) into ext4. FWIW, XFS and btrfs both use the page writeback bit correctly and never change a page while it is undergoing I/O. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
