Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mikko Rapeli <mikko.rapeli@linaro.org>,
	 openembedded-core@lists.openembedded.org
Cc: Ross Burton <ross.burton@arm.com>
Subject: Re: [OE-core] [PATCH] wic partition.py: add --apparent-size to du calls
Date: Tue, 27 Feb 2024 11:48:27 +0000	[thread overview]
Message-ID: <d7abf62f2c7e7312c93ce6ad066aa16f81f519c9.camel@linuxfoundation.org> (raw)
In-Reply-To: <20240227112357.2455578-1-mikko.rapeli@linaro.org>

On Tue, 2024-02-27 at 13:23 +0200, Mikko Rapeli wrote:
> If build happens on zfs filesystem with compression enabled,
> then image size calculations in do_image_wic task can fail:
> 
> output: mke2fs 1.47.0 (5-Feb-2023)
> Discarding device blocks: done
> Creating filesystem with 351999 4k blocks and 176000 inodes
> Filesystem UUID: 6091b3a4-ce08-3020-93a6-f755a22ef03b
> Superblock backups stored on blocks:
>         32768, 98304, 163840, 229376, 294912
> 
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (8192 blocks): done
> Copying files into the device: __populate_fs: Could not allocate
> block in ext2 filesystem while writing file "service-2.json"
> mkfs.ext4: Could not allocate block in ext2 filesystem while
> populating file system
> 
> du --help says:
> 
>       --apparent-size   print apparent sizes, rather than disk usage;
> although
>                           the apparent size is usually smaller, it
> may be
>                           larger due to holes in ('sparse') files,
> internal
>                           fragmentation, indirect blocks, and the
> like
> 
> du -b already includes --apparent-size.
> 
> Same issue reported also in
> https://lists.yoctoproject.org/g/poky/message/12389
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>


From memory we've gone around in circles on this. In some cases we do
really want the size in bytes but in others we want it rounded up to
block size for each file. I think this was why what bug was never fixed
as you can address one set of issues but create a new set.

So for that reason I'm extremely cautious about this, particularly this
late in the release cycle. I don't really know what to do with this
change.

Cheers,

Richard



  reply	other threads:[~2024-02-27 11:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 11:23 [PATCH] wic partition.py: add --apparent-size to du calls Mikko Rapeli
2024-02-27 11:48 ` Richard Purdie [this message]
2024-02-27 11:55   ` [OE-core] " Mikko Rapeli
2024-02-27 12:06     ` Richard Purdie
2024-02-27 12:23       ` Mikko Rapeli
2024-02-27 12:33         ` Richard Purdie
2024-02-29  7:30           ` Mikko Rapeli

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=d7abf62f2c7e7312c93ce6ad066aa16f81f519c9.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=mikko.rapeli@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@arm.com \
    /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