Received-SPF: pass (google.com: domain of linux-ext4+bounces-1757-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 218626] fstest ext4/014 fails when using filesystem quotas
Date: Tue, 26 Mar 2024 15:38:09 +0000
Message-ID: <bug-218626-13602-xYEOTpypHh@https.bugzilla.kernel.org/>
In-Reply-To: <bug-218626-13602@https.bugzilla.kernel.org/>
References: <bug-218626-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0

https://bugzilla.kernel.org/show_bug.cgi?id=3D218626

--- Comment #1 from Luis Henriques (luis.henriques@linux.dev) ---
Created attachment 306044
  --> https://bugzilla.kernel.org/attachment.cgi?id=3D306044&action=3Dedit
Fix lost+found directory

OK, I've a patch that seems to fix the issue.

When mke2fs creates the 'lost+found' directory, it ensures that there are a=
 few
empty blocks in it.  However, this test (ext4/014) corrupts the filesystem =
and
this directory needs to be created again.

The e2fsck program, however, when recreating the lost+found directory, isn't
making sure that there are these empty blocks.  These extra blocks will be =
then
taken into account in the quota calculation, as they were in the initial
(non-corrupted) filesystem.  The patch I'm attaching basically copies the l=
oop
that adds the blocks to the empty directory.  There are a few I haven't yet
understood -- for example, the '16*1024' magic number is still a mistery.

Any thoughts?

--=20
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.=