From: "Theodore Ts'o" <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: Michael Wu <michael@allwinnertech.com>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org,
allwinner-opensource-support@allwinnertech.com
Subject: Re: [PATCH] ext4: fix error when itable blocks is greater than s_itb_per_group
Date: Wed, 3 Aug 2022 22:19:03 -0400 [thread overview]
Message-ID: <Yussl4uRWAAO3TtT@mit.edu> (raw)
In-Reply-To: <20220803071859.elywnni2yfol4bea@fedora>
On Wed, Aug 03, 2022 at 09:18:59AM +0200, Lukas Czerner wrote:
>
> Hi Michael,
>
> mke2fs is making sure that we completely fill the inote table blocks.
> This is a corrupted image and so AFAICT ext4 is doing the right thing
> here. There does not seem to be a problem to fix, unless you can somehow
> trick mke2fs to make a file system like this.
Several years ago, android was shipping a bogus/busted
reimeplementation of mke2fs, reportedly because a certain founder of
Android (cough, Andy Rubin, cough) was alergic to the GPL. ("The
problem with GPL in embedded systems [such as smartphones and tablets]
is that it's viral...") This bogus reimplementation would create file
systems where the number of inodes per block group was a multiple of 4
instead of 8. But, it was under the BSD license, so it was all good! :-/
This bogus reimplementation of mkfs would, 50% of the time, create
busted file systems which couldn't be fixed, if they got corrupted, by
e2fsck. This is because e2fsprogs' allocation bitmap code assumes
that you can back the bitarray into a single contiguous memory block
--- and this doesn't work if the number of inodes per block group is
not a multiple of 8. If the file system got corrupted, the only
recourse was to wipe the user partition and the user would lose any
data that wasn't backed up to the cloud.
This has since been fixed for quite some time, but if there is some
low-end Android manufacturer is using an ancient version of AOSP, this
could be happening even in 2022 --- but that doesn't mean we need to
support such broken file systems. As far as I'm concerned the only
way to make valid Android ext4 system images is the combination of
mke2fs and e2fsdroid, which is what modern versions of AOSP do.
- Ted
next prev parent reply other threads:[~2022-08-04 2:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 2:10 [PATCH] ext4: fix error when itable blocks is greater than s_itb_per_group Michael Wu
2022-08-03 7:18 ` Lukas Czerner
2022-08-04 2:19 ` Theodore Ts'o [this message]
2022-08-06 4:02 ` Michael Wu
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=Yussl4uRWAAO3TtT@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=allwinner-opensource-support@allwinnertech.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@allwinnertech.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).