Re: FLUSH mechanism implementation in block layer

[Tanya Brokhman <tlinder@codeaurora.org>]

Hi Tejun,

Thank you for the prompt response.
>
> Which version of kernel are you looking at?  The barrier / flush
> implementation went through several iterations and in the current
> iteration ordering of requests around the flush request is the
> responsibility of higher layer - ie. filesystems are required to wait
> for completions of commands which should come before flush before
> issuing it.
>
> Thanks.
>


That is the conclusion I came to as well. I was looking at kernel3.4 but 
if I'm not mistaken it's the same at kernel3.7 as well.
Could you please tell me why it was designed this way? It seems to me 
that if the application is issuing async requests it shouldn't be the 
applications responsibility to wait for their completion if the 
execution order is important. I mean, it feels like the FLUSH should be 
implemented by the lower layers (block, device driver, card) and in the 
current situation, you may say that FLUSH is partially implemented by 
the application.
At first I didn't understand why in case of FLUSH the elevator is not 
drained. Later I understood that it's not efficient since there might be 
requests from other tasks as well there that can be completed after the 
FLUSH. But perhaps there is a correct way to move the implementation of 
"ordering around the flush" to the block layer? Not that it would work 
better, it just feels that logically - block layer is the place to do it 
at.
What do you think?

Best Regards,
Tanya Brokhman
-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation