Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   bugzilla-daemon@bugzilla.kernel.org
To:     linux-ext4@vger.kernel.org
Subject: [Bug 211971] Incorrect fix by e2fsck for blocks_count corruption
Date:   Wed, 03 Mar 2021 17:14:27 +0000
Message-ID: <bug-211971-13602-NudUPEa3VT@https.bugzilla.kernel.org/>
In-Reply-To: <bug-211971-13602@https.bugzilla.kernel.org/>
References: <bug-211971-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
Precedence: bulk

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

--- Comment #3 from tmahmud@iastate.edu ---
Hello Ted,

Thank you very much for the detailed clarification! It mostly makes sense to
me. But I still have two questions regarding the debugfs/e2fsck behavior.


(1)
> > > debugfs -w image
> > > debugfs:  ssv blocks_count 4000
> > > debugfs:  q
>=20
> This will update the blocks_count in the primary and all secondary
> backups.=20=20

This is different from what I observed. In my experiment, =E2=80=9Cdebugfs:=
 ssv
blocks_count 4000=E2=80=9D only updated the blocks_count (and the checksum)=
 in the
primary superblock. All secondary backups were not updated (neither the
blocks_count nor the checksum). Does this imply that there is a potential b=
ug
in debugfs (because it didn=E2=80=99t update all backups as you suggested)?=
  I=E2=80=99m
attaching two images before and after =E2=80=9Cdebugfs: ssv blocks_count 40=
00=E2=80=9D for
reference (=E2=80=9Cimage1_before=E2=80=9D, =E2=80=9Cimage1_after=E2=80=9D)=
. I have verified backups are not
updated by dumping the backup superblocks information with dumpe2fs.


(2)
> The problem is that e2fsck can't really determine that the blocks
> count field has been corrupted.=20=20

In my experiment, I observed that e2fsck was able to fix the debugfs-modifi=
ed
primary superblock using secondary superblocks when the secondary superbloc=
ks
are located in default locations (ex. 8193rd block). However, in an image w=
here
secondary superblocks are not in their default locations (ex:513rd block), I
found that e2fsck cannot fix the primary superblock using secondary
superblocks. So e2fsck=E2=80=99s behavior is inconsistent depending on the =
location of
the secondary superblocks. Could you please comment on this?

--=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.=