On Tue, Aug 2, 2011 at 7:07 PM, Round Robinjp <roundrobinjp@xxxxxxxxxxx> wrote: > Amir > >> > 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? It's not "so important" because it contains information that can be recovered, so fsck -fp can easily fix that. Do you have e2fsck on your embedded system? Can you run it on first boot? > Will things go wrong if I flash this 1G image to my eMMC > partition (without using Yongqiang's new 64bit resize patches)? I think the kernel will shout at you, mark the fs with error_fs flag and recommend that you run fsck. This will happen when you write files to the extended 3G. > I need to understand whether Yongqiang's patch is absolutely > necessary for this purpose or just a good thing to have. if you don't use it, you need to use the other method I mentioned using debugfs or run fsck on the MMC after you flashed the short image. > >> 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. > >> 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. > > Best Regards > Round > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
