Re: [PATCH v13 4/5] btrfs: test verity orphans with dmlogwrites

[Sweet Tea Dorminy <sweettea-kernel@dorminy.me>]

On 7/19/22 20:49, Boris Burkov wrote:
> The behavior of orphans is most interesting across mounts, interrupted
> at arbitrary points during fsverity enable. To cover as many such cases
> as possible, use dmlogwrites and dmsnapshot as in
> log-writes/replay-individual.sh. As we replay the log events, we run a
> state machine with different invariants enforced at each state.
> 
> There are three possible states for a given point in the log:
> 0. Verity has not yet started
> 1. Verity has started but not finished
> 2. Verity has finished.
> 
> The possible transitions with causes are:
> 0->1: We see an orphan item for the file.
> 1->2: Running 'fsverity measure' succeeds on the file.
> 
> Each state has its own invariant for testing:
> 0: No verity items exist.
> 1: Mount should handle the orphan and blow away verity data: expect 0
>     Merkle items after mounting.
> 2: The orphan should be gone and mount should not blow away merkle
>     items. Expect the same number of merkle items before and after
>     mounting.
> 
> As a result, we can be confident that if the file system loses power at
> any point during enabling verity on a file, the work is either completed,
> or gets rolled-back by mount.
> 
> Signed-off-by: Boris Burkov <boris@bur.io>
> Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>   tests/btrfs/291     | 168 ++++++++++++++++++++++++++++++++++++++++++++
>   tests/btrfs/291.out |   2 +
>   2 files changed, 170 insertions(+)
>   create mode 100755 tests/btrfs/291
>   create mode 100644 tests/btrfs/291.out
> 

Still looks good to me, with the fua-hunting rewrite.

It occurred to me last night that the test doesn't verify that it sees a 
disk state in state 1 -- theoretically it could go directly from state 0 
to state 2 -- but I don't see a good way to ensure the test spends time 
in state 1.