* generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs @ 2025-03-18 20:39 Eric Sandeen 2025-03-18 23:51 ` Theodore Ts'o 0 siblings, 1 reply; 13+ messages in thread From: Eric Sandeen @ 2025-03-18 20:39 UTC (permalink / raw) To: fstests@vger.kernel.org generic/699 fails because _overlay_mount_dirs() uses _common_dev_mount_options(), and when FSTYP is ext4, that yields "-o acl,user_xattr" and acl is not a valid option for overlayfs. Lots of overlayfs/ tests use _overlay_mount_dirs of course, but they run with ./check -overlay which sets FSTYP to overlay, not the underlying type. I'm ... not sure how this should be fixed. I have a hack to temporarily override FSTYP for the test, but that seems bad. Thoughts? Thanks, -Eric ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-18 20:39 generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs Eric Sandeen @ 2025-03-18 23:51 ` Theodore Ts'o 2025-03-19 0:58 ` Eric Sandeen 0 siblings, 1 reply; 13+ messages in thread From: Theodore Ts'o @ 2025-03-18 23:51 UTC (permalink / raw) To: Eric Sandeen; +Cc: fstests@vger.kernel.org On Tue, Mar 18, 2025 at 03:39:33PM -0500, Eric Sandeen wrote: > generic/699 fails because _overlay_mount_dirs() uses _common_dev_mount_options(), > and when FSTYP is ext4, that yields "-o acl,user_xattr" and acl is not a valid > option for overlayfs. Hmm, I hadn't noticed because the test is getting skipped for me: BEGIN TEST 4k (1 test): Ext4 4k block Tue Mar 18 19:44:51 EDT 2025 DEVICE: /dev/vdb EXT_MKFS_OPTIONS: -b 4096 EXT_MOUNT_OPTIONS: -o block_validity FSTYP -- ext4 PLATFORM -- Linux/x86_64 kvm-xfstests 6.14.0-rc2-xfstests-00063-g6630cf085eb0 #14 SMP PREEMPT_DYNAMIC Mon Mar 17 11:19:56 EDT 2025 MKFS_OPTIONS -- -F -q -b 4096 /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc generic/699 [19:44:51][ 12.536740] run fstests generic/699 at 2025-03-18 19:44:51 [ 12.794084] overlay: Unknown parameter 'acl' [19:44:52] [not run] generic/699 -- overlayfs doesn't support idmappped layers Ran: generic/699 I haven't really played with idmapped mount. Is there some CONFIG option I need to enable this test to run? - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-18 23:51 ` Theodore Ts'o @ 2025-03-19 0:58 ` Eric Sandeen 2025-03-19 3:58 ` Theodore Ts'o 2025-03-19 15:11 ` Zorro Lang 0 siblings, 2 replies; 13+ messages in thread From: Eric Sandeen @ 2025-03-19 0:58 UTC (permalink / raw) To: Theodore Ts'o; +Cc: fstests@vger.kernel.org On 3/18/25 6:51 PM, Theodore Ts'o wrote: > On Tue, Mar 18, 2025 at 03:39:33PM -0500, Eric Sandeen wrote: >> generic/699 fails because _overlay_mount_dirs() uses _common_dev_mount_options(), >> and when FSTYP is ext4, that yields "-o acl,user_xattr" and acl is not a valid >> option for overlayfs. > > Hmm, I hadn't noticed because the test is getting skipped for me: > > BEGIN TEST 4k (1 test): Ext4 4k block Tue Mar 18 19:44:51 EDT 2025 > DEVICE: /dev/vdb > EXT_MKFS_OPTIONS: -b 4096 > EXT_MOUNT_OPTIONS: -o block_validity > FSTYP -- ext4 > PLATFORM -- Linux/x86_64 kvm-xfstests 6.14.0-rc2-xfstests-00063-g6630cf085eb0 #14 SMP PREEMPT_DYNAMIC Mon Mar 17 11:19:56 EDT 2025 > MKFS_OPTIONS -- -F -q -b 4096 /dev/vdc > MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc > > generic/699 [19:44:51][ 12.536740] run fstests generic/699 at 2025-03-18 19:44:51 > [ 12.794084] overlay: Unknown parameter 'acl' > [19:44:52] [not run] > generic/699 -- overlayfs doesn't support idmappped layers > Ran: generic/699 > > I haven't really played with idmapped mount. Is there some CONFIG > option I need to enable this test to run? > > - Ted I shouldn't have said "failed" - you're seeing what I'm seeing, it's skipped (not failed) because it tries to test overlayfs idmapped layers using the ext4 default options, and acl mounts fail, skipping the test. -Eric ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 0:58 ` Eric Sandeen @ 2025-03-19 3:58 ` Theodore Ts'o 2025-03-19 15:36 ` Eric Sandeen 2025-03-19 15:11 ` Zorro Lang 1 sibling, 1 reply; 13+ messages in thread From: Theodore Ts'o @ 2025-03-19 3:58 UTC (permalink / raw) To: Eric Sandeen; +Cc: fstests@vger.kernel.org On Tue, Mar 18, 2025 at 07:58:05PM -0500, Eric Sandeen wrote: > > I shouldn't have said "failed" - you're seeing what I'm seeing, it's > skipped (not failed) because it tries to test overlayfs idmapped layers > using the ext4 default options, and acl mounts fail, skipping the test. Ah, OK. Hmm... I think the fundamental problem is that _overlay_mount_dirs() shouldn't be using _common_dev_mount_options(). Depending on the file system configuration that we might be testing, MOUNT_OPTIONS might include any number of things which overlayfs might not understand, including things like: "nfsvers=4", "data=journal", "dax", "test_dummy_encryption", "trans=virtio" ,"version=9p2000.L" ,"posixacl", "prjquota", and probably quite a few others. After all, we'd want to test overlayfs on top of (for exaple) 9pfs with generic/699, and in that case, MOUNT_OPTIONS will be set from PLAN9_MOUNT_OPTIONS, and will contain options like "version=9p2000.L" that overalyfs has no hope of handling. What I'm wondering is what mount options _overlay_mount_dirs() needs from _common_dev_mount_options()? Why is it there in the first place? If there are some specific mount options that we need to pass on to overlatyfs, maybe _overlay_mount_dirs() should be grepping out whatever mount options. it needs, instead of just blindly pulling all of the mount options? Or, maybe _overlay_mount_dirs() sould avoid calling _common_dev_mount_options if FSTYP != overlay? - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 3:58 ` Theodore Ts'o @ 2025-03-19 15:36 ` Eric Sandeen 0 siblings, 0 replies; 13+ messages in thread From: Eric Sandeen @ 2025-03-19 15:36 UTC (permalink / raw) To: Theodore Ts'o; +Cc: fstests@vger.kernel.org On 3/18/25 10:58 PM, Theodore Ts'o wrote: > On Tue, Mar 18, 2025 at 07:58:05PM -0500, Eric Sandeen wrote: >> >> I shouldn't have said "failed" - you're seeing what I'm seeing, it's >> skipped (not failed) because it tries to test overlayfs idmapped layers >> using the ext4 default options, and acl mounts fail, skipping the test. > > Ah, OK. > > Hmm... I think the fundamental problem is that _overlay_mount_dirs() > shouldn't be using _common_dev_mount_options(). I'm not sure but I think that's still necessary to get to OVERLAY_MOUNT_OPTIONS for overlayfs mounts ... > Depending on the file > system configuration that we might be testing, MOUNT_OPTIONS might > include any number of things which overlayfs might not understand, > including things like: "nfsvers=4", "data=journal", "dax", > "test_dummy_encryption", "trans=virtio" ,"version=9p2000.L" > ,"posixacl", "prjquota", and probably quite a few others. Right. > After all, we'd want to test overlayfs on top of (for exaple) 9pfs > with generic/699, and in that case, MOUNT_OPTIONS will be set from > PLAN9_MOUNT_OPTIONS, and will contain options like "version=9p2000.L" > that overalyfs has no hope of handling. > > What I'm wondering is what mount options _overlay_mount_dirs() needs > from _common_dev_mount_options()? Why is it there in the first place? > If there are some specific mount options that we need to pass on to > overlatyfs, maybe _overlay_mount_dirs() should be grepping out > whatever mount options. it needs, instead of just blindly pulling all > of the mount options? Or, maybe _overlay_mount_dirs() sould avoid > calling _common_dev_mount_options if FSTYP != overlay? Again I think that _common_dev_mount_options is intended to pick up any OVERLAY_MOUNT_OPTIONS mount options the user might have set. In this case, though, it picks up the underlying fs options, because in this case FSTYP is the underlying fs type, not overlay. I asked Zorro offline if maybe this test should just move into overlayfs/ if that can work. I think it would solve the issue, though I'm not familiar enough with what this test is doing to know if it's ok to only get this coverage with an explicit ./check -overlay run ... -Eric > - Ted > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 0:58 ` Eric Sandeen 2025-03-19 3:58 ` Theodore Ts'o @ 2025-03-19 15:11 ` Zorro Lang 2025-03-19 15:39 ` Zorro Lang 1 sibling, 1 reply; 13+ messages in thread From: Zorro Lang @ 2025-03-19 15:11 UTC (permalink / raw) To: Eric Sandeen; +Cc: Theodore Ts'o, fstests@vger.kernel.org On Tue, Mar 18, 2025 at 07:58:05PM -0500, Eric Sandeen wrote: > On 3/18/25 6:51 PM, Theodore Ts'o wrote: > > On Tue, Mar 18, 2025 at 03:39:33PM -0500, Eric Sandeen wrote: > >> generic/699 fails because _overlay_mount_dirs() uses _common_dev_mount_options(), > >> and when FSTYP is ext4, that yields "-o acl,user_xattr" and acl is not a valid > >> option for overlayfs. > > > > Hmm, I hadn't noticed because the test is getting skipped for me: > > > > BEGIN TEST 4k (1 test): Ext4 4k block Tue Mar 18 19:44:51 EDT 2025 > > DEVICE: /dev/vdb > > EXT_MKFS_OPTIONS: -b 4096 > > EXT_MOUNT_OPTIONS: -o block_validity > > FSTYP -- ext4 > > PLATFORM -- Linux/x86_64 kvm-xfstests 6.14.0-rc2-xfstests-00063-g6630cf085eb0 #14 SMP PREEMPT_DYNAMIC Mon Mar 17 11:19:56 EDT 2025 > > MKFS_OPTIONS -- -F -q -b 4096 /dev/vdc > > MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc > > > > generic/699 [19:44:51][ 12.536740] run fstests generic/699 at 2025-03-18 19:44:51 > > [ 12.794084] overlay: Unknown parameter 'acl' > > [19:44:52] [not run] > > generic/699 -- overlayfs doesn't support idmappped layers > > Ran: generic/699 > > > > I haven't really played with idmapped mount. Is there some CONFIG > > option I need to enable this test to run? > > > > - Ted > > I shouldn't have said "failed" - you're seeing what I'm seeing, it's > skipped (not failed) because it tries to test overlayfs idmapped layers > using the ext4 default options, and acl mounts fail, skipping the test. How about changing as below? diff --git a/tests/generic/699 b/tests/generic/699 index 620a40aa..3ca92254 100755 --- a/tests/generic/699 +++ b/tests/generic/699 @@ -100,7 +100,8 @@ reset_ownership() setup_overlayfs_idmapped_lower_metacopy_off() { mkdir -p $upper $work $merge - _overlay_mount_dirs $lower $upper $work \ + # Ignore the MOUNT_OPTIONS isn't for overlay + MOUNT_OPTIONS="" _overlay_mount_dirs $lower $upper $work \ overlay $merge -ometacopy=off || \ _notrun "overlayfs doesn't support idmappped layers" } @@ -109,7 +110,8 @@ setup_overlayfs_idmapped_lower_metacopy_off() setup_overlayfs_idmapped_lower_metacopy_on() { mkdir -p $upper $work $merge - _overlay_mount_dirs $lower $upper $work overlay $merge -ometacopy=on + # Ignore the MOUNT_OPTIONS isn't for overlay + MOUNT_OPTIONS="" _overlay_mount_dirs $lower $upper $work overlay $merge -ometacopy=on } reset_overlayfs() > > -Eric > ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 15:11 ` Zorro Lang @ 2025-03-19 15:39 ` Zorro Lang 2025-03-19 16:44 ` Theodore Ts'o 0 siblings, 1 reply; 13+ messages in thread From: Zorro Lang @ 2025-03-19 15:39 UTC (permalink / raw) To: Eric Sandeen, Christian Brauner Cc: Theodore Ts'o, fstests@vger.kernel.org On Wed, Mar 19, 2025 at 11:11:44PM +0800, Zorro Lang wrote: > On Tue, Mar 18, 2025 at 07:58:05PM -0500, Eric Sandeen wrote: > > On 3/18/25 6:51 PM, Theodore Ts'o wrote: > > > On Tue, Mar 18, 2025 at 03:39:33PM -0500, Eric Sandeen wrote: > > >> generic/699 fails because _overlay_mount_dirs() uses _common_dev_mount_options(), > > >> and when FSTYP is ext4, that yields "-o acl,user_xattr" and acl is not a valid > > >> option for overlayfs. > > > > > > Hmm, I hadn't noticed because the test is getting skipped for me: > > > > > > BEGIN TEST 4k (1 test): Ext4 4k block Tue Mar 18 19:44:51 EDT 2025 > > > DEVICE: /dev/vdb > > > EXT_MKFS_OPTIONS: -b 4096 > > > EXT_MOUNT_OPTIONS: -o block_validity > > > FSTYP -- ext4 > > > PLATFORM -- Linux/x86_64 kvm-xfstests 6.14.0-rc2-xfstests-00063-g6630cf085eb0 #14 SMP PREEMPT_DYNAMIC Mon Mar 17 11:19:56 EDT 2025 > > > MKFS_OPTIONS -- -F -q -b 4096 /dev/vdc > > > MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc > > > > > > generic/699 [19:44:51][ 12.536740] run fstests generic/699 at 2025-03-18 19:44:51 > > > [ 12.794084] overlay: Unknown parameter 'acl' > > > [19:44:52] [not run] > > > generic/699 -- overlayfs doesn't support idmappped layers > > > Ran: generic/699 > > > > > > I haven't really played with idmapped mount. Is there some CONFIG > > > option I need to enable this test to run? > > > > > > - Ted > > > > I shouldn't have said "failed" - you're seeing what I'm seeing, it's > > skipped (not failed) because it tries to test overlayfs idmapped layers > > using the ext4 default options, and acl mounts fail, skipping the test. > > How about changing as below? > > diff --git a/tests/generic/699 b/tests/generic/699 > index 620a40aa..3ca92254 100755 > --- a/tests/generic/699 > +++ b/tests/generic/699 > @@ -100,7 +100,8 @@ reset_ownership() > setup_overlayfs_idmapped_lower_metacopy_off() > { > mkdir -p $upper $work $merge > - _overlay_mount_dirs $lower $upper $work \ > + # Ignore the MOUNT_OPTIONS isn't for overlay > + MOUNT_OPTIONS="" _overlay_mount_dirs $lower $upper $work \ > overlay $merge -ometacopy=off || \ > _notrun "overlayfs doesn't support idmappped layers" > } > @@ -109,7 +110,8 @@ setup_overlayfs_idmapped_lower_metacopy_off() > setup_overlayfs_idmapped_lower_metacopy_on() > { > mkdir -p $upper $work $merge > - _overlay_mount_dirs $lower $upper $work overlay $merge -ometacopy=on > + # Ignore the MOUNT_OPTIONS isn't for overlay > + MOUNT_OPTIONS="" _overlay_mount_dirs $lower $upper $work overlay $merge -ometacopy=on > } > > reset_overlayfs() Oh, I rememeber this case now. Christian wrote a big test case to test idmapped mount: https://lore.kernel.org/fstests/20220615092826.2333847-1-brauner@kernel.org/ That case tests underlying fs and overlay fs together. I helped to split it to two cases, one for basic fs, one for overlay fs: https://lore.kernel.org/fstests/20220920115035.2472076-1-zlang@kernel.org/ I've forgotten why I left g/699 to generic, not in overlay. Maybe Christian hope to run these two cases together in one FSTYP test round (don't need to run overlay test once). I'm good to move this case to tests/overlay/, cc Christian to check his review point. Hi Christian, do you hope to move this case to overlay, or just roughly change it as above patch? Thanks, Zorro > > > > > -Eric > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 15:39 ` Zorro Lang @ 2025-03-19 16:44 ` Theodore Ts'o 2025-03-19 16:54 ` Eric Sandeen 2025-03-19 20:01 ` Zorro Lang 0 siblings, 2 replies; 13+ messages in thread From: Theodore Ts'o @ 2025-03-19 16:44 UTC (permalink / raw) To: Zorro Lang; +Cc: Eric Sandeen, Christian Brauner, fstests@vger.kernel.org On Wed, Mar 19, 2025 at 11:39:02PM +0800, Zorro Lang wrote: > > I've forgotten why I left g/699 to generic, not in overlay. Maybe > Christian hope to run these two cases together in one FSTYP test > round (don't need to run overlay test once). I'm good to move this > case to tests/overlay/, cc Christian to check his review point. I had assumed it was because we might want to test the combination of overlayfs with a variety of different underlying file systems? If we move this to tests/overlay, I'd still be able to do this kind of testing via: {gce,kvm}-xfstests --primary-fstype {ext4,xfs} -c overlay/default -g auto This allows me to test overlayfs with the underlying upper and lower directories being either ext4 or xfs. (I could and should extend this to support other base file system types, via some minor changes to test-appliance/files/root/fs/overlay/config, but I had never gotten around to it.) How do other people who are testing overlayfs handle this? - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 16:44 ` Theodore Ts'o @ 2025-03-19 16:54 ` Eric Sandeen 2025-03-19 20:01 ` Zorro Lang 1 sibling, 0 replies; 13+ messages in thread From: Eric Sandeen @ 2025-03-19 16:54 UTC (permalink / raw) To: Theodore Ts'o, Zorro Lang; +Cc: Christian Brauner, fstests@vger.kernel.org On 3/19/25 11:44 AM, Theodore Ts'o wrote: > On Wed, Mar 19, 2025 at 11:39:02PM +0800, Zorro Lang wrote: >> >> I've forgotten why I left g/699 to generic, not in overlay. Maybe >> Christian hope to run these two cases together in one FSTYP test >> round (don't need to run overlay test once). I'm good to move this >> case to tests/overlay/, cc Christian to check his review point. > > I had assumed it was because we might want to test the combination of > overlayfs with a variety of different underlying file systems? don't we already get that with ./check -overlay while the fundamental test/scratch devices are formatted with the underlying filesystem you wish to test with overlayfs? note that AFAICT generic/699 is the only test which explicitly exercises overlayfs outside of tests/overlayfs/ ... (right?) -Eric > If we move this to tests/overlay, I'd still be able to do this kind of > testing via: > > {gce,kvm}-xfstests --primary-fstype {ext4,xfs} -c overlay/default -g auto > > This allows me to test overlayfs with the underlying upper and lower > directories being either ext4 or xfs. (I could and should extend this > to support other base file system types, via some minor changes to > test-appliance/files/root/fs/overlay/config, but I had never gotten > around to it.) > > How do other people who are testing overlayfs handle this? > > - Ted > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 16:44 ` Theodore Ts'o 2025-03-19 16:54 ` Eric Sandeen @ 2025-03-19 20:01 ` Zorro Lang 2025-03-19 23:32 ` Theodore Ts'o 1 sibling, 1 reply; 13+ messages in thread From: Zorro Lang @ 2025-03-19 20:01 UTC (permalink / raw) To: Theodore Ts'o Cc: Eric Sandeen, Christian Brauner, fstests@vger.kernel.org On Wed, Mar 19, 2025 at 12:44:10PM -0400, Theodore Ts'o wrote: > On Wed, Mar 19, 2025 at 11:39:02PM +0800, Zorro Lang wrote: > > > > I've forgotten why I left g/699 to generic, not in overlay. Maybe > > Christian hope to run these two cases together in one FSTYP test > > round (don't need to run overlay test once). I'm good to move this > > case to tests/overlay/, cc Christian to check his review point. > > I had assumed it was because we might want to test the combination of > overlayfs with a variety of different underlying file systems? > > If we move this to tests/overlay, I'd still be able to do this kind of > testing via: > > {gce,kvm}-xfstests --primary-fstype {ext4,xfs} -c overlay/default -g auto > > This allows me to test overlayfs with the underlying upper and lower > directories being either ext4 or xfs. (I could and should extend this > to support other base file system types, via some minor changes to > test-appliance/files/root/fs/overlay/config, but I had never gotten > around to it.) > > How do other people who are testing overlayfs handle this? Hi Ted, 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 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). Thanks, Zorro > > - Ted > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 20:01 ` Zorro Lang @ 2025-03-19 23:32 ` Theodore Ts'o 2025-03-20 5:25 ` Zorro Lang 0 siblings, 1 reply; 13+ messages in thread From: Theodore Ts'o @ 2025-03-19 23:32 UTC (permalink / raw) To: Zorro Lang; +Cc: Eric Sandeen, Christian Brauner, fstests@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-19 23:32 ` Theodore Ts'o @ 2025-03-20 5:25 ` Zorro Lang 2025-03-20 7:50 ` Amir Goldstein 0 siblings, 1 reply; 13+ messages in thread From: Zorro Lang @ 2025-03-20 5:25 UTC (permalink / raw) To: Theodore Ts'o Cc: Eric Sandeen, Christian Brauner, fstests@vger.kernel.org On Wed, Mar 19, 2025 at 07:32:42PM -0400, Theodore Ts'o wrote: > 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). Yeah, that's why I left this case in generic/, I thought Christian Brauner might want that -- "do this idmapped mount test on overlay, no matter he tests on each kind of underlying fs". So I cc Christian Brauner, to check if that's his purpose. > > 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. Sure, thanks for you look into it :) Thanks, Zorro > > Cheers, > > - Ted > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs 2025-03-20 5:25 ` Zorro Lang @ 2025-03-20 7:50 ` Amir Goldstein 0 siblings, 0 replies; 13+ messages in thread From: Amir Goldstein @ 2025-03-20 7:50 UTC (permalink / raw) To: Zorro Lang Cc: Theodore Ts'o, Eric Sandeen, Christian Brauner, fstests@vger.kernel.org On Thu, Mar 20, 2025 at 6:25 AM Zorro Lang <zlang@redhat.com> wrote: > > On Wed, Mar 19, 2025 at 07:32:42PM -0400, Theodore Ts'o wrote: > > 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). > > Yeah, that's why I left this case in generic/, I thought Christian Brauner > might want that -- "do this idmapped mount test on overlay, no matter he > tests on each kind of underlying fs". So I cc Christian Brauner, to check > if that's his purpose. > I don't think that's not the reason - the reason is that the integration of idmapped tests and ./check -overlay is not trivial when overlayfs idmapped mount are not supported. > > > > 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. > There is another generic test that "_require_extra_fs overlay" and is not an "overlayfs test" - generic/631. This test open codes mount -t overlay explicitly. _overlay_mount_dirs was written as a helper for overlayfs tests that run with ./check -overlay. We could fix generic/699 with MOUNT_OPTIONS="" _overlay_mount_dirs Since there is not really much in this helper, my preference is to open code mount -t overlay, but I don't mind the former. Thanks, Amir. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2025-03-20 7:50 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-03-18 20:39 generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs Eric Sandeen 2025-03-18 23:51 ` Theodore Ts'o 2025-03-19 0:58 ` Eric Sandeen 2025-03-19 3:58 ` Theodore Ts'o 2025-03-19 15:36 ` Eric Sandeen 2025-03-19 15:11 ` Zorro Lang 2025-03-19 15:39 ` Zorro Lang 2025-03-19 16:44 ` Theodore Ts'o 2025-03-19 16:54 ` Eric Sandeen 2025-03-19 20:01 ` Zorro Lang 2025-03-19 23:32 ` Theodore Ts'o 2025-03-20 5:25 ` Zorro Lang 2025-03-20 7:50 ` Amir Goldstein
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.