On Thursday December 1, neilb@xxxxxxx wrote: > > I'd probably be happy to consider the 'verified read' enhancements to > md for inclusion in mainline. A couple more thoughts on this: 1/ What do you do for a 'verified read' when the array is degraded. For raid1, you can just check whichever devices are working, but for raid5 you really need to report a read error! 2/ Quoting from the end of section 4.3 ] ] Finally, an option is added to the software RAID-5 ] layer to disable resynchronization after a crash. This ] is our most signicant modication to the strict layering ] of the storage stack. The RAID module is asked to en- ] trust its functionality to another component for the over- ] all good of the system. Instead, an apprehensive software ] RAID implementation may delay its own efforts in hopes ] of receiving the necessary verify read requests from the ] file system above. If no such requests arrive, it could ] start its own resynchronization to ensure the integrity of ] its data and parity blocks. ] I agree that this modification doesn't feel ideal. An alternate approach would be to have a 'verifiable write' (or some other more apt name). The meaning is that the write request says essentially "don't mark the array as 'dirty' just because of this request". The implication is that the after a crash, the fs will do any 'verified reads' that are required. If write-intent logging were in use, 'verifiable writes' wouldn't get recorded in the log and so wouldn't get resynced. If two different filesystems were sharing the array (via partitioning) then the part which got only verifiable writes would not be resynced, but the part which got normal writes would be. (If write-intent logging weren't in use, then it will still be an all-or-nothing situation). Maybe swap could then use 'verifiable writes' so that the swap partition would never need to be resynced. NeilBrown - 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
