On Wed, Apr 13, 2022 at 03:49:07PM -0700, Eric Wheeler wrote: > On Tue, 22 Mar 2022, Eric Wheeler wrote: > > On Mon, 21 Mar 2022, Ming Lei wrote: > > > On Sat, Mar 19, 2022 at 10:14:29AM -0700, Eric Wheeler wrote: > > > > Hello all, > > > > > > > > In loop.c do_req_filebacked() for REQ_OP_FLUSH, lo_req_flush() is called: > > > > it does not appear that lo_req_flush() does anything to make sure > > > > ki_complete has been called for pending work, it just calls vfs_fsync(). > > > > > > > > Is this a consistency problem? > > > > > > No. What FLUSH command provides is just flushing cache in device side to > > > storage medium, so it is nothing to do with pending request. > > > > If a flush follows a series of writes, would it be best if the flush > > happened _after_ those writes complete? Then then the storage medium will > > be sure to flush what was intended to be written. > > > > It seems that this series of events could lead to inconsistent data: > > loop -> filesystem > > write a > > write b > > flush > > write a > > flush > > write b > > crash, b is lost > > > > If write+flush ordering is _not_ important, then can you help me > > understand why? > > > > Hi Ming, just checking in: did you see the message above? > > Do you really mean to say that reordering writes around a flush is safe > in the presence of a crash? As I explained before, FLUSH doesn't provide order guarantee, and that is supposed to be done by upper layer, such FS. Again, what FLUSH does is just to flush cache in device side to medium, that is it. Thanks, Ming
