write barrier in RAID5

write barrier in RAID5

[Eric Mei]

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

Re: write barrier in RAID5

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Wed, 01 Apr 2015 12:24:38 -0600 Eric Mei <meijia@gmail.com> wrote:

> 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?

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


> 
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]