openembedded-core.lists.openembedded.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: charles-antoine.couret@mind.be
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 0/3] image_types: use IMAGE_FILE_MAXSIZE variable to create fixed partition size
Date: Wed, 7 Jun 2023 11:52:24 +0200	[thread overview]
Message-ID: <20230607095224e1009509@mail.local> (raw)
In-Reply-To: <20230604123755.2541295-1-charles-antoine.couret@mind.be>

Hello,

On 04/06/2023 14:37:52+0200, Charles-Antoine Couret via lists.openembedded.org wrote:
> In case of fixed partitionning where the rootfs partition can't exceed an
> amount of bytes, there is currently no automatic and no generic way to have
> this requirement met in any case.
> 
> Until now, ROOTFS_SIZE value got from directory_size() does not takes into account
> the size of required metadata for the filesystem itself (and does not work well
> for other block size than 4k BTW).
> Obviously it's a difficult task which depends on rootfs size and filesystem type.
> 
> The workaround was to set IMAGE_OVERHEAD_FACTOR and IMAGE_ROOTFS_EXTRA_SPACE
> to add the required extra margins. But when the final rootfs is closed to the
> maximum size, it's difficult to adjust them correctly  And if you remove
> or add new recipes in your image, you've to recompute these margins to have enough
> space for these metadata when the rootfs is small, and to not have too big final
> file when the rootfs is big.
> 
> It's cumbersome and error prone to just have a build failure when the final output
> can't be flashed into the partition.
> 
> The solution is to follow how it's implemented in buildroot by having a
> specific variable, here IMAGE_FILE_MAXSIZE, to create the final sparse file
> and trying to fill it with the content of rootfs. If there is enough space,
> margins are well compressed and does not consume space in the filesystem.
> If there is no enough space, an error is triggered to warm the developer before
> trying to use it in the device.
> 
> If IMAGE_FILE_MAXSIZE is not set, the idea is to keep the previous behaviour
> for compatibility reason and to met other requirements.

It would be great if you could add test cases that ensure that the
generated images are indeed fitting the size.

> 
> Charles-Antoine Couret (3):
>   image_types: use IMAGE_FILE_MAXSIZE variable for ext2/3/4 image types
>   image_types: use IMAGE_FILE_MAXSIZE variable for btrfs image types
>   image_types: use IMAGE_FILE_MAXSIZE variable for f2fs image types
> 
>  meta/classes-recipe/image_types.bbclass | 34 +++++++++++++++++++------
>  1 file changed, 26 insertions(+), 8 deletions(-)
> 
> -- 
> 2.40.1
> 

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#182359): https://lists.openembedded.org/g/openembedded-core/message/182359
> Mute This Topic: https://lists.openembedded.org/mt/99320002/3617179
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alexandre.belloni@bootlin.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  parent reply	other threads:[~2023-06-07  9:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-04 12:37 [PATCH 0/3] image_types: use IMAGE_FILE_MAXSIZE variable to create fixed partition size Charles-Antoine Couret
2023-06-04 12:37 ` [PATCH 1/3] image_types: use IMAGE_FILE_MAXSIZE variable for ext2/3/4 image types Charles-Antoine Couret
2023-06-07 12:30   ` [OE-core] " Alexandre Belloni
2023-06-04 12:37 ` [PATCH 2/3] image_types: use IMAGE_FILE_MAXSIZE variable for btrfs " Charles-Antoine Couret
2023-06-04 12:37 ` [PATCH 3/3] image_types: use IMAGE_FILE_MAXSIZE variable for f2fs " Charles-Antoine Couret
2023-06-07  9:52 ` Alexandre Belloni [this message]
2023-07-06 11:57 ` [OE-core] [PATCH 0/3] image_types: use IMAGE_FILE_MAXSIZE variable to create fixed partition size Ross Burton

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=20230607095224e1009509@mail.local \
    --to=alexandre.belloni@bootlin.com \
    --cc=charles-antoine.couret@mind.be \
    --cc=openembedded-core@lists.openembedded.org \
    /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;
as well as URLs for NNTP newsgroup(s).