From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/mke2img: use mkfs to generate rootfs image
Date: Mon, 6 Mar 2017 14:24:25 +0100 [thread overview]
Message-ID: <20170306142425.670ab5ab@free-electrons.com> (raw)
In-Reply-To: <9ba789cc-143e-2102-56be-90793313af23@armadeus.com>
Hello,
On Mon, 6 Mar 2017 14:20:56 +0100, S?bastien Szymanski wrote:
> 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.
I'm wondering if XFS also doesn't store very small files, and possibly
symbolic links, in a different way.
In any case, I believe we agree that looking at the size of files
stored in filesystem A doesn't give an accurate idea of how much space
they will consume once stored with filesystem B.
> > 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,
How do you know which one to choose? If you look at the target
directory size, then you end up doing what you do today, and which is
broken. Or you have to take some really really big margin. But OK, we
can try with even margin (like 20% or 30% margin).
> and then we shrink the filesystem with resize2fs -M ?
Why would you shrink it down? The fact that our filesystem images today
are really just the size of the files they contain is most of time
annoying, and you have to increase the size of the filesystem
afterwards to make the system usable. So it'd be great to instead have
images of 64 MB, 128 MB, 256 MB, with some free space.
Of course, we should have options to allow the user to indicate the
size he wants, and comply with this size exactly.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-03-06 13:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 9:06 [Buildroot] [PATCH 1/1] package/mke2img: use mkfs to generate rootfs image Sébastien Szymanski
2017-03-02 10:34 ` Thomas Petazzoni
2017-03-02 12:45 ` Sébastien Szymanski
2017-03-02 12:47 ` Thomas Petazzoni
2017-03-06 13:20 ` Sébastien Szymanski
2017-03-06 13:24 ` Thomas Petazzoni [this message]
2017-03-07 8:18 ` Arnout Vandecappelle
2017-03-18 14:30 ` Yann E. MORIN
2017-03-18 14:42 ` Arnout Vandecappelle
2017-03-20 15:24 ` Sébastien Szymanski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170306142425.670ab5ab@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox