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? Sorry, replied too quick. BTW, what is the actual crash? Any dmesg log? From the above description, b is just not flushed to storage when running flush, and sooner or later it will land, so what is the real issue? Thanks, Ming
