On Mon, Nov 27, 2017 at 08:23:49AM -0600, Ashlie Martinez wrote: > Amir, > > Just to throw in what I believe I've found about dm-log-writes (though > Josef would know more about this as it's just what I've concluded > after looking at the code): dm-log-writes logs at IO completion, > meaning disks that ignore flush operations could exhibit bugs where > there are none, and dm-log-writes does synchronous marks though this > may not line up with the stream of IO operations (due to buffering) > unless you just did a sync. The CrashMonkey team wanted to make > something similar to the "mark" operation dm-log-writes has and we > concluded that the only place we could guarantee a mark would line up > with the stream of IO operations the user had performed was right > after a call to sync as that would force cached updates to disk. If > you call mark without a sync, then you could insert a mark after a > write(2) returns, but before the delayed allocation for that write(2) > actually allocates blocks and changes the extent tree on disk. > Yeah dm-log-writes gladly hands you the loaded gun, it's your job to not shoot yourself with it. This fsx test is specifically set up to only do the mark _after_ a successful call of fsync(), which means that the mark will be after where we expect our data to be consistent. Thanks, Josef
