xfstests: add zfs support to latest xfstests

[behlendorf]

Recent updates to CentOS 7, Ubuntu 16.04, and almost certain other modern versions of Linux have resulted in xfstests no longer building. The failures have been resolved in current versions of xfstests. What needs to happen is for our patch stack to be rebased on the latest xfstests and then submitted upstream for inclusion.

[stale[bot]]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[implr]

I might take a stab at rebasing this over a weekend. It's a bit hard to piece together what is the current state though. Can you confirm that branch zfs of https://github.com/zfsonlinux/xfstests is the latest version of the patchset, or does someone somewhere have something further along?

[behlendorf]

@implr that would be very welcome. That is the latest version of the branch I'm aware of, I believe xfstests has changed considerably since it was last updated so you might want to use those commits as a guide of what needs to be updated to get things going. I'd love to be able to add xfstests to our regular testing.

[implr]

Yeah I had a brief look already, rebasing those patches over a decade of changes is hopeless. From scratch shouldn't be too bad though. Another thing is that xfstests gained a bunch of zfs-relevant tests because of btrfs (reflinks, dedup, etc). Those might be a bit harder to get working due to btrfs specifics, but making generic run looks very doable.

[implr]

Small progress update: I have a partial patch at https://github.com/implr/xfstests/tree/zfs. I tested on ubuntu2204 for now with their packaged zfs, so I didn't try any of the reflink/FICLONE tests yet. I used this local.config:

export TEST_DEV=test/t
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/vdc
# will be destroyed/recreated, pick a name that doesn't exist on your system
export SCRATCH_ZPOOL_NAME=scrat
export SCRATCH_MNT=/mnt/scratch

Note SCRATCH_DEV is a block device. I kept @behlendorf's "TEST_DEV is a fs name" approach for convenience, but I really wanted scratch to be a blkdev, as that would allow us to try the various dm-flakey tests (and perhaps even the btrfs pool tests). However, that ended up being quite complicated, as ZFS pools are identified by names, while a lot of parts of xfstests really want to be able to just mount $SCRATCH_DEV. I fixed it for the general case, but a lot of the devmapper stuff remains broken.

A bunch of other tests fail too. Some of them look like I'm missing things in the port, some are more suspicious, but I didn't have time to debug them yet. exclude.zfs.txt has the list.

[implr]

I've moved onto getting the reflink tests to run and ran into a problem. xfstests checks if the fs supports clone_range like this. That always fails on zfs for two reasons:

1. 64k < default recordsize, so it fails with EINVAL
2. it creates and then clones the file immediately after, which usually falls within the same txg, so zfs returns EAGAIN (and xfs_io doesn't retry)

While 1 is trivial to work around (lower recordsize on the test fs, or just patch the 64k to something bigger), I don't really know what to do about 2. For a proper fix we could patch xfs_io, but that might take a while to upstream, and meanwhile be tedious to manage (it's a separate thing, not part of xfstests). A workaround would be waiting for the next txg, but how? I guess there's always an option for a few second sleep, but that's really stupid.

Any ideas?

[behlendorf]

15842 should be the fix for 2. It would be particularly helpful if you could run the reflink tests with that PR. Hopefully it'll help us identify any other places where ZFS behaves differently than the other Linux filesystem which support reflink.