[Buildroot] [PATCH 1/1] package/mke2img: use mkfs to generate rootfs image

Sébastien Szymanski sebastien.szymanski at armadeus.com
Mon Mar 6 13:20:56 UTC 2017


Hi,

On 03/02/2017 01:47 PM, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 2 Mar 2017 13:45:06 +0100, Sébastien Szymanski wrote:
> 
>>> Now that we use mkfs, is it possible to get rid of mke2img entirely?  
>>
>> We still have to calculate the number of blocks needed. I guess we can
>> do that in the .mk file, can't we?
> 
> Do we still need to do this calculation? Can't mkfs create an image of
> an arbitrary size in MBs ?
> 
> Indeed, the current code that calculates the number of blocks needed is
> completely bogus, and breaks as soon as the host filesystem is not
> ext2/3/4. We have two bug reports that says it doesn't work, one one
> ZFS, another on NTFS, and I remember it also broke on XFS.
> 
> See:
> 
>   https://bugs.busybox.net/show_bug.cgi?id=8831 (ZFS)
>   https://bugs.busybox.net/show_bug.cgi?id=9496 (NTFS)
>   https://github.com/buildroot/buildroot-defconfig-testing/blob/master/.travis.yml#L158 (XFS)
> 
> So the whole "let's calculate how many blocks are needed" logic we have
> simply cannot work, because the number of blocks needed completely
> depends on the internal architecture of the filesystem.

I copied the target/ directory on a xfs filesystem and looked the
differences. On ext4, the size of a directory is at least the size of
block. With find, we can get the number of directories with a size less
than the size of a block:

XFS fs
$ du -s -k /mnt/target
16032

Ext4 fs (4K block size):
$ du -s -k output/target
16320

$ find /mnt/target/ -type d -size -1024c | wc -l
72

16032 + 72*4 = 16320

I didn't check if this is true with other filesystems.

> 
> Therefore, I would suggest that we get rid of this, and instead add an
> option "Filesystem size" in Config.in, default to some reasonable value
> like 64M or 128M, and it would be up to the user to define it to a
> value that is large enough to host the package selection he has done.

Can't we automate this? I mean depending of the size of the target
directory, we use one of the following size: 64M, 128M, 256M,
and then we shrink the filesystem with resize2fs -M ?

Regards,

> 
>>>> +    # Disable some defaults features
>>>> +    mkfs_O_opts+=",^ext_attr,^64bit,^flex_bg,^large_file,^huge_file,^dir_nlink,^extra_isize"  
>>>
>>> Why would we disable these default features  
>>
>> I disable these default features, to generate a rootfs as similar as
>> possible the one generated by genext2fs.
> 
> OK.
> 
>> U-boot had some issues with rootfs with the 64bit flags, but this has
>> been fixed
>>
>> http://git.denx.de/?p=u-boot.git;a=commit;h=b4976b49a01ac68f7dbb33657a44dcffe584fa4a
> 
> Then, I think we want to disable it by default indeed, since we want to
> remain compatible with old U-Boot versions that may not have this fix.
> 
> Thomas
> 


-- 
Sébastien Szymanski
Software Engineer, Armadeus Systems
sebastien.szymanski at armadeus.com
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26


More information about the buildroot mailing list