On Thu, Mar 20, 2025 at 04:01:42AM +0800, Zorro Lang wrote: > Fstests supports overlayfs testing with different underlying fs, for example > if you want to test overlay with ext4, you can set local.config as: > > FSTYP=ext4 > TEST_DEV=/dev/sdb > TEST_DIR=/mnt/test > SCRATCH_DEV=/dev/sdc > SCRATCH_MNT=/mnt/scratch Yes, I know. My test appliances has autmation around setting local.config > > then does: > # mkfs.ext4 -F $TEST_DEV > # mkfs.ext4 -F $SCRACH_DEV > # mkdir /mnt/test > # mkdir /mnt/scratch > # ./check -overlay -g auto > > For more details you can refer to xfstests/README.overlay. > > Currently fstests only supports overlayfs testing as this, other fs, e.g. nfs, > has to prepare nfs SCRATCH_DEV and TEST_DEV by the user. I'm thinking about > supporting other upper fs testing likes overlay (if it's helpful). I have automation that handles this, so I'm good: ./kvm-xfstests --primary-fstype xfs -c overlay/default -g auto My point was that might be the reason why it might be convenient for the test generic/699 being in generic/ instead of overlay/, since it means that people who are runing a large number of configs, e.g.: ./kvm-xfstests -c ext4/default,xfs/default,btrfs/default generic/699 can easily test overlayfs with idmapping with different underlying file systems. (Note: this is where my automation will write to local.config while iterating across different file system configs). Is it worth regularly running generic/699 across multiple underyling file systmes? I dunno; I'll let other people chime in on it, since I don't really use overayfs with idmapping myself, and I haven't examined the code paths in question myself. Cheers, - Ted
