On Tue, Nov 23, 2010 at 10:50:00AM +1100, Neil Brown wrote: > On Mon, 22 Nov 2010 15:22:08 -0800 > "Darrick J. Wong" <djwong@xxxxxxxxxx> wrote: > > > Before 2.6.37, the md layer had a mechanism for catching I/Os with the barrier > > flag set, and translating the barrier into barriers for all the underlying > > devices. With 2.6.37, I/O barriers have become plain old flushes, and the md > > code was updated to reflect this. However, one piece was left out -- the md > > layer does not tell the block layer that it supports flushes or FUA access at > > all, which results in md silently dropping flush requests. > > > > Since the support already seems there, just add this one piece of bookkeeping > > to restore the ability to flush writes through md. > > I would rather just unconditionally call > blk_queue_flush(mddev->queue, REQ_FLUSH | REQ_FUA); > > I don't think there is much to be gained by trying to track exactly what the > underlying devices support, and as the devices can change, that is racy > anyway. > > Thoughts? I don't think there's anything that would get confused by an md that advertises flush/fua support when any of the underlying devices don't support it, but that was the only reason why I didn't just code it up your way to start with. :) None of the in-kernel code checks queue->flush_flags except the block layer itself, and the block layer silently strips off REQ_FLUSH/REQ_FUA if the device doesn't support it. I'm not sure I like /that/ behavior, but at the moment I have no objection. dm hardcodes the flags on as well. --D -- 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
