Hey, Amir, Miklos,
On 29/10/24 14:13, Ian Kent wrote:
On 29/10/24 13:44, Ian Kent wrote:
On 29/10/24 07:13, Dave Chinner wrote:
On Tue, Oct 29, 2024 at 03:28:04AM +0800, Zorro Lang wrote:
On Mon, Oct 28, 2024 at 01:22:52PM +0100, Christian Brauner wrote:
On Sun, Oct 27, 2024 at 02:07:41AM +0800, Zorro Lang wrote:
Hi,
Recently, I hit lots of fstests cases fail on overlayfs (xfs
underlying, no
specific mount options), e.g.
FSTYP -- overlay
PLATFORM -- Linux/s390x s390x-xxxx 6.12.0-rc4+ #1 SMP Fri
Oct 25 14:29:18 EDT 2024
MKFS_OPTIONS -- -m
crc=1,finobt=1,rmapbt=0,reflink=1,inobtcount=1,bigtime=1
/mnt/fstests/SCRATCH_DIR
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0
/mnt/fstests/SCRATCH_DIR /mnt/fstests/SCRATCH_DIR/ovl-mnt
generic/294 [failed, exit status 1]- output mismatch (see
/var/lib/xfstests/results//generic/294.out.bad)
--- tests/generic/294.out 2024-10-25 14:38:32.098692473
-0400
+++ /var/lib/xfstests/results//generic/294.out.bad
2024-10-25 15:02:34.698605062 -0400
@@ -1,5 +1,5 @@
QA output created by 294
-mknod: SCRATCH_MNT/294.test/testnode: File exists
-mkdir: cannot create directory
'SCRATCH_MNT/294.test/testdir': File exists
-touch: cannot touch 'SCRATCH_MNT/294.test/testtarget':
Read-only file system
-ln: creating symbolic link 'SCRATCH_MNT/294.test/testlink':
File exists
+mount: /mnt/fstests/SCRATCH_DIR/ovl-mnt: fsconfig system
call failed: overlay: No changes allowed in reconfigure.
+ dmesg(1) may have more information after failed
mount system call.
In the new mount api overlayfs has been changed to reject invalid
mount
option on remount whereas in the old mount api we just igorned them.
Not only g/294 fails on new mount utils, not sure if all of them
are from same issue.
If you need, I can paste all test failures (only from my side) at
here.
If this a big problem then we need to change overlayfs to continue
ignoring garbage mount options passed to it during remount.
Do you mean this behavior change is only for overlayfs, doesn't
affect other fs?
We tried this with XFS years ago, and reverted back to the old
behaviour of silently ignoring mount options we don't support in
remount. The filesystem code has no idea what mount API
userspace is using for remount - it can't assume that it is ok to
error out on unknown/unsupported options because it uses
the fsreconfigure API internally....
I expect that remounting to change options for overlayfs has very
limited use
cases. Perhaps remounting (the upper layer) read-only is useful ...
Actually, my mistake, it looks like remount read-only might be the
only case that should
be handled (provided the sb is not already read-only). In this case it
does a file system
sync and returns the result of that but now fails unconditionally in
fsconfig().
What is the right thing to do here for overlayfs?
Does it even make sense to remount overlayfs to change mount options?
The file system sync on read-only-remount seems worth while so assuming
it is kept
what should be returned from other remount requests, fail or silently
fail as before?
Ian
The problem here is that xfstests wants to remount the mount
read-only in this
test which has never actually been done so xfstests reporting a
failure has no
value!
Ian
