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@xxxxxx>
Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx>
---
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.
