From: "Theodore Ts'o" <tytso@mit.edu>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>
Subject: Re: generic/699 fails on ext4 due to using ext4 mount options w/ overlayfs
Date: Tue, 18 Mar 2025 23:58:15 -0400 [thread overview]
Message-ID: <20250319035815.GG787758@mit.edu> (raw)
In-Reply-To: <ffed04f3-5743-4a92-9b2c-20887c04a4cf@sandeen.net>
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
next prev parent reply other threads:[~2025-03-19 3:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250319035815.GG787758@mit.edu \
--to=tytso@mit.edu \
--cc=fstests@vger.kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.