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