Date:   Wed, 4 Jul 2018 01:54:12 +0000
From:   "Gaoming (ming, consumer BG)" <gaoming20@...wei.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
CC:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Liqingchao (sorp)" <sorp.liqingchao@...wei.com>,
        "Shenchen (harry)" <harry.shen@...wei.com>,
        "miaoxie (A)" <miaoxie@...wei.com>,
        "yangfei (D)" <yangfei39@...wei.com>,
        "Renlipeng (OS driver)" <renlipeng@...wei.com>
Subject: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

Hi,

I do not think Huawei has hacked make_ext4fs.
For it could be reproduced in make_ext4fs master brach before Jun 21th 2018. Like below,
I think we just choose not recommended parameter "-b 1024" for small partition like below, but it's legal though not good. 

./host/linux-x86/bin/make_ext4fs  -s -l 20M -b 1024 gaoming.img 
Creating filesystem with parameters:
    Size: 20971520
    Block size: 1024
    Blocks per group: 8192
    Inodes per group: 1708
    Inode size: 256
    Journal blocks: 1024
    Label:
    Blocks: 20480
    Block groups: 3
    Reserved block group size: 95
Created filesystem with 11/5124 inodes and 2509/20480 blocks

Other vendors may choose this para, or not, we don't know. maybe they are lucky or wise not choosing 1024.

Of course we will choose 4096, or mke2fs from now on.

We just want to fix historical problem. We will fix it by ourselves.
I fully understand your attitude.
Thanks a lot.

Regards,
Ming

-----邮件原件-----
发件人: Theodore Y. Ts'o [mailto:tytso@....edu] 
发送时间: 2018年7月4日 0:03
收件人: Gaoming (ming, consumer BG)
抄送: linux-ext4@...r.kernel.org; linux-kernel@...r.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver)
主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

On Tue, Jul 03, 2018 at 11:15:21AM +0000, Gaoming (ming, consumer BG) wrote:
> 
> You misunderstand my question.  Why was the choice of a blocksize of
> 1024 made?
> 
> -----some one choose, not me . I guess they want get more inodes in 20M filesystem.

That can't be the explanation.

I just checked the sources for make_ext4fs; the blocksize was
hard-coded, as was the number of inodes.  So in order to use a
block_size of 1024 bytes, someone must have hacked the sources
directly and modified compute_block_size().  And in fact, it would
have been *easier* to simply hack compute_inodes() which is just a few
lines below in make_ext4fs.c:

static u32 compute_block_size()
{
	return 4096;
}

static u32 compute_inodes()
{
	return DIV_ROUND_UP(info.len, info.block_size) / 4;
}


This also means commit 06c35f935a7a which fixed make_ext4fs.c wasn't
buggy; it was a valid fix given the complete-non-adjustability of the
blocksize in make_ext4fs.  Yes, it's not a great fix, since it was
fragile --- but that's hardly the smallest problem in make_ext4fs,
there was plenty of other super-fragile bits in make_ext4fs.  There's
a *reason* I was pushing hard to make make_ext4fs go away.

That being said, given the block size of make_ext4fs was hard-coded to
4096, it makes it clear that the change to make it create a blocksize
of 1024 must have beeen a Huawei-local change, and it was never sent
back to the the common AOSP tree.  (If it had, I would have gotten an
e-mail, and I would have explained to whoever had made this
Huawei-local hack why it was such a incredibly bad idea.)


In any case, what I would recommend at this point if you need to
support Huawei devices that do this, is that you keep your e2fsprogs
as a Huawei-specific e2fsprogs repo.

> How long has Huawei been using a 1024 byte blocksize?  And why?  And
> for how many devices?  Essentially, I'm trying to figure out if this
> was a Huawei-specific mistake.
> ----- I cannot answer this question.

Well, actually, it should be very easy for you to detremine the answer
this question --- it should just be a matter of checking git source
control history and see which product trees has the change to
platforms/system/extras/ext4_utils/make_ext4fs.c --- and you must have
platform-specific source trees in order to be compliant with the GNU
Public License (GPL).

Even if you didn't, it would just be a matter using dumpe2fs or
debugfs (they aren't built by default in e2fsprogs by the AOSP build
trees, but they should be buildable) to those Huawei devices that you
still support, and then run either dumpe2fs or debugfs via adb shell
and see what block size is reported.

Even if you aren't allowed to answer this question publically, I'd
strongly recommend you figure it out, so you know when your local
change to e2fsprogs can be dropped.  I'd further recommend that you
make sure all new Huawei devices use a block size of 4096, preferably
using mke2fs and e2fsdroid, as is currently done in AOSP.  Failing
that, at least please use the stock make_ext4fs which doesn't have the
Huawei-specific hack to support 1024 byte block sizes, or have that
Huawei-specific hack reverted.

Regards,

						- Ted

Powered by blists - more mailing lists