From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mikko Rapeli <mikko.rapeli@linaro.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 12:33:15 +0000 [thread overview]
Message-ID: <27646d1e2d357dbe208c9950d6a03a433aa01409.camel@linuxfoundation.org> (raw)
In-Reply-To: <Zd3UXd9ks9FWKH8Q@nuoska>
On Tue, 2024-02-27 at 14:23 +0200, Mikko Rapeli wrote:
> On Tue, Feb 27, 2024 at 12:06:41PM +0000, Richard Purdie wrote:
> > Should we break it for others so it works for you?
> >
> > If I merge this patch and then I get other reports in of issues,
> > I'm
> > going to be left to somehow fix those other problems. Since your
> > case
> > will work you will object if I revert this but you likely won't
> > have
> > time to work on the resulting other issues, or be able to reproduce
> > them since you're building on zfs.
> >
> > So you can see my dilemma? :/
> >
> > Most people don't build on zfs which is probably what I need to
> > balance
> > this on.
>
> What if I make this optional for zfs? If build directory type is zfs,
> then --apparent-size is added, else not.
Wouldn't that cause some really interesting bug reports?
Asking the user to report their host system filesystem type to debug
anything isn't going to be great.
I don't like the idea of the non-determinism that introduces but I
agree we do already have a determinism issue.
What we probably need is the absolute files size, plus a number of
files and a number of directories, then you can round up to the worst
cases for the block size.
Currently that size number is just including the block sizes.
Cheers,
Richard
next prev parent reply other threads:[~2024-02-27 12:33 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
2024-02-27 12:06 ` Richard Purdie
2024-02-27 12:23 ` Mikko Rapeli
2024-02-27 12:33 ` Richard Purdie [this message]
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=27646d1e2d357dbe208c9950d6a03a433aa01409.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