From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] fs/ext2: add options for extra space and extra inodes
Date: Fri, 30 Oct 2015 13:54:20 +0100 [thread overview]
Message-ID: <5633687C.6010504@mind.be> (raw)
In-Reply-To: <20151030123518.GA3713@free.fr>
On 30-10-15 13:35, Yann E. MORIN wrote:
> Arnout, All,
>
> On 2015-10-30 12:01 +0100, Arnout Vandecappelle spake thusly:
>> On 29-10-15 00:06, Yann E. MORIN wrote:
>>> Add two options to the ext2 filesystem, one to add extra free space, one
>>> to add extra free inodes.
>>>
>>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>>> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
[snip]
>>> +config BR2_TARGET_ROOTFS_EXT2_EXTRA_BLOCKS
>>> + int "extra size in blocks" if BR2_TARGET_ROOTFS_EXT2_BLOCKS = 0
>>> + default 0
>>> + help
>>> + Enter here the nmuber of extra blocks of free space you
>>> + want on your filesystem. By default, Buildroot will not
>>> + leave much space free.
>>
>> To be precise, buildroot will add 500 extra blocks for ext2 and 1800 extra
>> blocks for ext3+. So perhaps we could encode that here, and remove it from the
>> mke2img script?
>
> I don't want to do that, because the extra blocks and inodes that
> Buildroot adds are just to account for the extra space required to
> store the filesystem metadata.
>
> If we were to encode those here in the kconfig option, nothing would
> prevent the user from setting this to a value lower than strictly
> required.
>
> In Kconfig, we can provide a range, but no a lower (or upper) bound to a
> value. And we do not want to limit the user in the values he may want to
> set here (even to an insanely large value for the upper bound.
>
> I would really prefer we hide this internal complex computation from the
> user, and let him specify the extra space he actually wants.
OK fair enough.
>>> +config BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES
>>> + int "extra inodes" if BR2_TARGET_ROOTFS_EXT2_INODES = 0
>>> + default 0
>>> + help
>>> + Enter here the nmuber of extra free inodes you want on
>>> + your filesystem. By default, Buildroot will not leave
>>> + many free inodes.
>>
>> Same here, 400 inodes are added.
>
> Ditto.
>
>>> config BR2_TARGET_ROOTFS_EXT2_RESBLKS
>>> int "reserved blocks percentage"
>>> default 0
>>> diff --git a/fs/ext2/ext2.mk b/fs/ext2/ext2.mk
>>> index cab66a5..7417f81 100644
>>> --- a/fs/ext2/ext2.mk
>>> +++ b/fs/ext2/ext2.mk
>>> @@ -9,10 +9,12 @@ EXT2_OPTS = -G $(BR2_TARGET_ROOTFS_EXT2_GEN) -R $(BR2_TARGET_ROOTFS_EXT2_REV)
>>> ifneq ($(strip $(BR2_TARGET_ROOTFS_EXT2_BLOCKS)),0)
>>> EXT2_OPTS += -b $(BR2_TARGET_ROOTFS_EXT2_BLOCKS)
>>> endif
>>> +EXT2_OPTS += -B $(BR2_TARGET_ROOTFS_EXT2_EXTRA_BLOCKS)
>>
>> Perhaps this could be put into the else of the ifneq? Or better yet, make it an
>> ifeq.
>
> Well, the fact that the prompt has a condition before it is displayed
> will ensure that BR2_TARGET_ROOTFS_EXT2_EXTRA_BLOCKS/INODES is always
> set to a non-empty value, so we can safely use it. If the user specified
> the exact size/inodes, then the extra size/indoes will be set to 0.
I meant it more as a refactoring that makes the code easier to understand, but
you may have a different opinion of what is easier, so:
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
--
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
next prev parent reply other threads:[~2015-10-30 12:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 23:06 [Buildroot] [PATCH] fs/ext2: add options for extra space and extra inodes Yann E. MORIN
2015-10-29 10:45 ` Martin Bark
2015-10-29 18:17 ` Yann E. MORIN
2015-10-29 18:18 ` Gustavo Zacarias
2015-10-30 11:01 ` Arnout Vandecappelle
2015-10-30 12:35 ` Yann E. MORIN
2015-10-30 12:54 ` Arnout Vandecappelle [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-10-29 9:00 [Buildroot] [PATCH v3 0/2] Alternative way to wait interfaces on bootup Jérôme Pouiller
2015-10-29 9:00 ` [Buildroot] [PATCH v3 2/2] skeleton: optionally wait for network interfaces to appear Jérôme Pouiller
2015-10-29 20:26 ` [Buildroot] [PATCH] fs/ext2: add options for extra space and extra inodes Yann E. MORIN
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=5633687C.6010504@mind.be \
--to=arnout@mind.be \
--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