Re: FLUSH mechanism implementation in block layer

[Tejun Heo <tj@kernel.org>]

Hey,

On Sun, Apr 07, 2013 at 04:15:30PM +0300, Tanya Brokhman wrote:
> I've been looking into the flush implementation, trying to
> understand how it works. FLUSH command can be used for two purposes:
> 1. Flush the data to the non-volatile memory from the card cache
> 2. Keep an order of requests: req_A.... req_D, FLUSH, req_C...req_X
> Unfortunately I don't understand how the second purpose of FLUSH is
> implemented. If to simplify the question, let take for example a
> card that doesn't implement a writeback cache (doesn't support
> FLUSH/FUA) and the following example:
> 
> The application inserts req_A...req_D to the block layer (and the
> scheduler) and issues req_FLUSH that contains data. What is expected
> in this situation is that req_A..req_D will be written to the
> non-volatile memory before req_FLUSH.
> According to the code at blk_insert_flush() the req_FLUSH request
> will be marked as SOFTBARRIER and added to the tail of the dispatch
> queue.
> But what guaranties that by the time it's added to the dispatch
> queue req_A..req_D have been dispatched as well? It's possible that
> they are still in scheduler and will be dispatched only after
> req_FLUSH is completed...

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.

-- 
tejun