On Tue, Aug 2, 2011 at 7:07 PM, Round Robinjp [off-list ref] wrote:

Amir

quoted

quoted

But after extending to 4G, e2fsck makes some complain.
I guess this is not expected behaviour, is it?

it is expected when you use the current resize2fs,
which does not respect the flex_bg layout, so new group block bitmaps
are allocated beyond the 1G border and initialized.

So that means I have thrown away some important part of
the filesystem when I did truncate -s 1G, isn't it?
Will things go wrong if I flash this 1G image to my eMMC
partition (without using Yongqiang's new 64bit resize patches)?
I need to understand whether Yongqiang's patch is absolutely
necessary for this purpose or just a good thing to have.

quoted

if you use Yongqiang's new 64bit resize patches, the final fsck won't complain.
unfortunately for you, those patches have not been merged to the kernel yet,
so you will have to either build your own ext4 module or wait at least until
kernel 3.2 is released to have it in mainline.

As said above.

quoted

It is actually quite simple to fix the 1G image, so it will pass fsck
after truncate -s 4G.
All it takes it setting the BLOCK_UNINIT flag in groups 8-31
this should be possible to do with debugfs (or write a small tool to do it).
if I have time, it will try it myself and post the instructions.

OK, thanks in advance.

You are welcome ;-)
https://raw.github.com/amir73il/e2fsprogs-snapshots/next4-stable/contrib/uninit_bg.c


so after resize2fs to 4G, you need to umount the image and run:

amir@qalab:~$ gcc -o uninit_bg -lext2fs uninit_bg.c
amir@qalab:~$ uninit_bg -f a.img 8
uninit_bg: uninitializing filesystem a.img groups [8..31]
uninit_bg: found 514 used blocks in group 8!
uninit_bg: found super block backup in group 9!
uninit_bg: found 579 used blocks in group 9!
uninit_bg: found 514 used blocks in group 10!
uninit_bg: found 514 used blocks in group 11!
uninit_bg: found 514 used blocks in group 12!
uninit_bg: found 514 used blocks in group 13!
uninit_bg: found 514 used blocks in group 14!
uninit_bg: found 514 used blocks in group 15!
uninit_bg: found 514 used blocks in group 16!
uninit_bg: found 514 used blocks in group 17!
uninit_bg: found 514 used blocks in group 18!
uninit_bg: found 514 used blocks in group 19!
uninit_bg: found 514 used blocks in group 20!
uninit_bg: found 514 used blocks in group 21!
uninit_bg: found 514 used blocks in group 22!
uninit_bg: found 514 used blocks in group 23!
uninit_bg: found 514 used blocks in group 24!
uninit_bg: found super block backup in group 25!
uninit_bg: found 579 used blocks in group 25!
uninit_bg: found 514 used blocks in group 26!
uninit_bg: found super block backup in group 27!
uninit_bg: found 579 used blocks in group 27!
uninit_bg: found 514 used blocks in group 28!
uninit_bg: found 514 used blocks in group 29!
uninit_bg: found 514 used blocks in group 30!
uninit_bg: found 514 used blocks in group 31!

now you have an fs you can truncate to 1G.
fsck will complain about one small thing.
the complian is not relevant for your use case,
because you don't intent to resize that fs again
and the last group is full if you are using round size like 4G.

amir@qalab:~$ truncate -s 1G a.img
amir@qalab:~$ truncate -s 4G a.img
amir@qalab:~$ e2fsck -nf a.img
e2fsck 1.41.14 (22-Dec-2010)
Last group block bitmap uninitialized.  Fix? no

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
a.img: 2204/262144 files (0.3% non-contiguous), 86720/1048576 blocks



Amir.