From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 218626] New: fstest ext4/014 fails when using filesystem quotas
Date: Fri, 22 Mar 2024 11:54:19 +0000 [thread overview]
Message-ID: <bug-218626-13602@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=218626
Bug ID: 218626
Summary: fstest ext4/014 fails when using filesystem quotas
Product: File System
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: ext4
Assignee: fs_ext4@kernel-bugs.osdl.org
Reporter: luis.henriques@linux.dev
Regression: No
Created attachment 306024
--> https://bugzilla.kernel.org/attachment.cgi?id=306024&action=edit
full test log
I've started looking into a failure in fstest ext4/014. It's very easy to
reproduce, it simply has to be executed with quotas (without enabling quotas
the test passes).
Here's the fstests options I'm using:
export MOUNT_OPTIONS="-o quota"
export MKFS_OPTIONS="-O quota"
And here's the output (the last line is where the test fails):
QA output created by 014
+ create scratch fs
+ mount fs image
+ make some files
+ check fs
+ corrupt image
+ mount image
+ modify files
broken: 1
+ repair fs
+ mount image (2)
+ chattr -R -i
+ modify files (2)
broken: 0
+ check fs (2)
fsck should not fail
Basically, the test corrupts the first block of the root directory by doing the
following
- create and mount the filesystem
- create a few files
- unmount filesystem
- debugfs -w -R "zap -f / 0" <dev>
- mount, and attempt to modify some of the files created before, and unmount
After this last unmount, e2fsck attempts to fix the filesystem, including the
quota info. It exits with exit code '1' ('File system errors corrected'),
which is what the test expects.
However, after yet another filesystem mount/unmount cycle, another e2fsck run
will still complain about quota info being inconsistent.
The test will pass if another e2fsck is run immediately after the first one,
which seems to indicate there's some fix missing in the first pass, but I
couldn't figure out what (the code isn't particularly easy to grasp...).
On the other end, I'd also expect that the kernel would notice that something
was wrong when the filesystem is mounted after e2fsck is run, but dmesg doesn't
show anything.
For reference, I'm attaching the full test log that includes the output of
e2fsck.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next reply other threads:[~2024-03-22 11:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 11:54 bugzilla-daemon [this message]
2024-03-26 15:38 ` [Bug 218626] fstest ext4/014 fails when using filesystem quotas bugzilla-daemon
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=bug-218626-13602@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-ext4@vger.kernel.org \
/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.