write barrier in RAID5
I can see how FUA is handled, but REQ_FLUSH seems problematic. My understanding of REQ_FLUSH semantics: all requests before the flush request must *complete* before the flush request complete. For IO remap layer like MD, we need to guarantee all previous requests are *submitted* to component devices before submitting the flush request. Is that correct?
If so why I don't see the code which make sure the pending write requests in stripe cache are processed & submitted before submit_flushes() get called? Thanks
Eric
Quoted 6 lines · On Wed, 01 Apr 2015 12:24:38 -0600 Eric Mei <[email protected]> wrote:
I can see how FUA is handled, but
REQ_FLUSHseems problematic. My understanding ofREQ_FLUSHsemantics: all requests before the flush request must *complete* before the flush request complete. For IO remap layer like MD, we need to guarantee all previous requests are *submitted* to component devices before submitting the flush request. Is that correct?
No.
See Documentation/block/writeback_cache_control.txt
Only "previously completed" requests are affect by REQ_FLUSH.
So any code using REQ_FLUSH must first wait for previous requests to complete, and then submit REQ_FLUSH. The REQ_FLUSH will not return until the data written by those requests is actually in stable storage, rather than write-behind cache.
NeilBrown
Quoted 10 lines
If so why I don't see the code which make sure the pending write requests in stripe cache are processed & submitted before
submit_flushes()get called? ThanksEric
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html