Hey, Vivek. On Tue, May 24, 2011 at 06:32:20PM -0400, Vivek Goyal wrote: > I think documentation is fine. It specifically talks about completed > requests. The requests which have been sent to drive (and may be in > controller's cache). > > So in above example, if driver holds back WRITE1 and never signals > the completion of request, then I think it is fine to complete > the WRITE3+FLUSH ahead of WRITE1. Yeap, that's correct. Ordering between flush and other writes are now completely the responsibility of filesystems. Block layer just doesn't care. > I think issue will arise only if you signaled that WRITE1 has completed > and cached it in driver (as you seem to indicating) and never sent to the > drive and then you received WRITE3 + FLUSH requests. In that case you shall > have to make sure that by the time WRITE3 + FLUSH completion is signaled, > WRITE1 is on the disk. A FLUSH command means "flush out all data from writes upto this point". If a driver has indicated completion of a write and then received a FLUSH, the data from the write should be written to disk. > > Again this does not appear to be illegal, as the FLUSH operation is > > not defined as a barrier, meaning it should in theory be possible > > to handle (and write to disk) requests received after the > > FLUSH request before the FLUSH request finishes, provided that the > > commands received before the FLUSH request itself complete before > > the FLUSH request is replied to. I really don't know what the answer > > is to this one. It makes a big difference to me as I can write multiple > > blocks in parallel, and would really rather not slow up future write > > requests until everything is flushed unless I need to. > > IIUC, you are right. You can finish WRITE4 before completing FLUSH+WRITE3 > here. > > We just need to make sure that any request completed by the driver > is on disk by the time FLUSH+WRITE3 completes. Yeap, again, block layer just doesn't care and the only thing block driver should pay attention to regarding FLUSH is implementing FLUSH command properly. Thanks. -- tejun -- 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
