From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org,
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 13:55:14 +0200 [thread overview]
Message-ID: <Zd3NolrDmgFmAOG5@nuoska> (raw)
In-Reply-To: <d7abf62f2c7e7312c93ce6ad066aa16f81f519c9.camel@linuxfoundation.org>
Hi,
On Tue, Feb 27, 2024 at 11:48:27AM +0000, Richard Purdie wrote:
> 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.
I have a build machine with zfs and this issue pops up ever now and then.
Right now I can't build there without this change. I don't see a way to
fix this issue in my build/host specific configuration.
Cheers,
-Mikko
next prev parent reply other threads:[~2024-02-27 11:55 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 ` [OE-core] " Richard Purdie
2024-02-27 11:55 ` Mikko Rapeli [this message]
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=Zd3NolrDmgFmAOG5@nuoska \
--to=mikko.rapeli@linaro.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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