All of lore.kernel.org
 help / color / mirror / Atom feed
* 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  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  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 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.