Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 3 Aug 2022 22:19:03 -0400
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
Message-ID: <Yussl4uRWAAO3TtT@mit.edu>
References: <20220802021029.16046-1-michael@allwinnertech.com>
 <20220803071859.elywnni2yfol4bea@fedora>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220803071859.elywnni2yfol4bea@fedora>
Precedence: bulk

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