On Tue, May 24, 2011 at 06:32:20PM -0400, Vivek Goyal wrote: > On Tue, May 24, 2011 at 10:29:09PM +0100, Alex Bligh wrote: > > [..] > > Q3: Apparently there are no longer concepts of barriers, just REQ_FLUSH > > and REQ_FUA. REQ_FLUSH guarantees all "completed" I/O requests are written > > to disk prior to that BIO starting. However, what about non-completed I/O > > requests? For instance, is the following legitimate: > > > > Receive Send to disk Reply > > ======= ============ ===== > > WRITE1 > > WRITE2 > > WRITE2 (cached) > > FLUSH+WRITE3 > > WRITE2 > > WRITE3 > > WRITE3 > > WRITE4 > > WRITE4 > > WRITE4 > > WRITE1 > > WRITE1 > > > > Here WRITE1 was not 'completed', and thus by the text of > > Documentation/writeback_cache_control.txt, need not be written to disk > > before starting WRITE3 (which had REQ_FLUSH attached). > > > > >The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from > > >the filesystem and will make sure the volatile cache of the storage device > > >has been flushed before the actual I/O operation is started. This > > >explicitly guarantees that previously completed write requests are on > > >non-volatile storage before the flagged bio starts. Are you writing a bio based driver? For a request based driver request queue should break down FLUSH + WRITE3 request in two parts. Issue FLUSH first and when that completes, issue WRITE3. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
