Received-SPF: pass (google.com: domain of linux-ext4+bounces-1660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 205197] kernel BUG at fs/ext4/extents_status.c:884
Date: Fri, 15 Mar 2024 12:14:32 +0000
Message-ID: <bug-205197-13602-BV4AeT3Ahn@https.bugzilla.kernel.org/>
In-Reply-To: <bug-205197-13602@https.bugzilla.kernel.org/>
References: <bug-205197-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=3D205197

--- Comment #7 from Antony Amburose (antony.ambrose@in.bosch.com) ---
Thank you for the response. I understand now , why there was not much atten=
tion
to this issue. Sorry for providing a minimal information in the first
communication...
 We have back-ported the interesting changes from upstream (~70 of them) an=
d=20
could still see the problem. I have reported the issue based on old kernel =
to
have the continuity. The old  issue reported as well seen while mounting an
encrypted sd card and we have also seen this on an encrypted volume, but its
onboard storage. I thought it is logical to continue the discussion here as=
 you
had given some debugging hints and issue did not progress as the old report=
er
could not reproduce the problem but we could even after backporting the cha=
nge.
I will create the bug based on the latest kernel in future. Thanks for the
hint.=20

The issue could be reproduced in a sequence where we interrupt the power. F=
rom
our decade long experience working with ext4, we have never seen an issue w=
here
we could corrupt the ext4 volume in a way that it is not mountable  by
executing a power loss sequence. That was main reason to report the issue to
the community experts. Ofcourse we have some paid support and also inhouse
kernel engineers, and I thought it is also better to report to the community
experts as the old bug is still open and we have a reliable reproduction .My
current assumption is either that we have a problem with our sequence or
problem with handling encrypted ext4 partition.

Regarding our knowhow and usage of tooling , we can work with the hex dump =
and
understand the ext4 disk layout and also work with the e2fsprogs to debug t=
he
problem. Hence, we expect only some debugging hints and direction and hopef=
ully
we try to solve the issues together.

As the device resets cyclically , we could not hook into the device and get=
 the
/dev/sdXX . The existing tooling only get the encrypted data .We will try to
resolve this situation and somehow get the hex dump and provide more detail=
s on
the nature of corruption and will also provide the fsck output.

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