On Sat, Nov 28, 2020 at 10:56 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > I notice you maintain overlay tests outside of the kernel. Unfortunately, I > > think for this kind of test, it requires in kernel code to artificially bump the > > writeback error count on the upperdir, or it requires the failure injection > > infrastructure. > > > > Simulating this behaviour is non-trivial without in-kernel support: > > > > P1: Open(f) -> p1.fd > > P2: Open(f) -> p2.fd > > P1: syncfs(p1.fd) -> errrno > > P2: syncfs(p1.fd) -> 0 # This should return an error > > > > failure injection is an option. xfstest generic/019 is an example. > generic/108 uses a different method and generic/361 uses a plain > loop image over commit without any fault injection to trigger writeback > errors. > > With current xfstests, check -overlay run (runs all generic tests with > overlayfs over the configured base fs) all the 3 tests mentioned above > will be skipped because of _require_block_device, but the requirement > is there for a different reason for each of them. > > At first look, the loop device approach is the most generic one and could > easily work also with overlayfs, so you could create an overlay specific > test (non generic) based on generic/361, but it is not easy to use the > helper _scratch_mkfs_sized, because check -overlay runs do not mkfs > the base scratch fs. > > My recommendation would be to fix generic/019 in a similar manner > to the way that tests that _require_scratch_shutdown were fixed to run > with check -overlay: > > * Instead of _require_block_device, add a specific helper > _require_scratch_fail_make_request, which like _require_scratch_shutdown > knows how to deal with overlay FSTYP correctly > > * Instead of `_sysfs_dev $SCRATCH_DEV` use a helper _scratch_sysfs_dev > that knows how to deal with overlay FSTYP correctly > I missed: * Instead of `blockdev --getsz $SCRATCH_DEV` use helper _scratch_blockdev_getsz > This will add test coverage to overlayfs fsync/syncfs and then you can > do one or both of: > 1. Run 'check -overlay generic/019' with OVERLAY_MOUNT_OPTIONS="volatile" > 2. Fork an overlay specific test from the generic test that will test the > volatile error handling on every 'check -overlay -g quick' run > > #2 will provide better coverage against regressions in volatile writeback error > handling and will be a good start for a test to reuse a volatile mount after > writeback errors. > > Thanks, > Amir.
