Re: mismatch_cnt again

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Peter" == Peter Rabbitson <rabbit+list@rabbit.us> 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