On Mon, Jul 18, 2022 at 04:01:47PM -0400, Sweet Tea Dorminy wrote: > > > > > > > I'm not understanding the snapshot part. It seems like most tests > > > using > > > log-writes do `_log_writes_replay_log_range $cur $SCRATCH_DEV >> > > > $seqres.full` to start each iteration; and then it seems like this > > > test can > > > check the item counts before and after a > > > _scratch_mount/_scratch_umount > > > cycle and get the same results. (And, if that worked, the test > > > wouldn't > > > need its own _cleanup() and its own lv management, I think?) But I'm > > > probably missing something. > > > > IIRC, the purpose of the snapshots is that the mount/unmount cycle is > > destructive in the middle of the operation. If the orphan is present, > > we'll blow up all the verity items, so if we did it on the device we > > were replaying onto, it would leave it in a messed up state as we kept > > replaying. So we snapshot at each entry and mount/unmount that to check > > the invariants. > > I think what you're saying is that we can't use the device itself instead of > the snapshot, because mount/unmount change the underlying device, and this > definitely makes sense. > > Looking at other dmlogwrites users, though, generic/482 looks like it does > something similar, and I don't understand what the difference between the > replay+snapshot+mount cycles here and the replay+mount cycles there. I > probably just don't understand what the difference between the two tests' > scenarios is, though. I just noticed a comment in generic/482 that I think explains it: # We don't care to preserve any data on the replay dev, as we can replay # back to the point we need, and in fact sometimes creating/deleting # snapshots repeatedly can be slower than replaying the log. So it looks to me like those tests re-replay the full log, including whatever the mkfs preamble stuff is onto replaydev for each FUA. That would work for me, I just assumed snapshots would be more efficient, though this comment challenges that assumption. Also, it looks like that tests tracks the prev entry redundantly. Looking into its history, it looks like it was always that way, but evolved into that state from originally being more like my test. https://patchwork.kernel.org/project/linux-btrfs/patch/20180314090230.25055-3-wqu@xxxxxxxx/#21608233
