All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: michael@amarulasolutions.com, Xuanhao Shi <X15000177@gmail.com>,
	Thomas Petazzoni via buildroot <buildroot@buildroot.org>,
	Dario Binacchi <dario.binacchi@amarulasolutions.com>,
	linux-amarula@amarulasolutions.com,
	Anand Gadiyar <gadiyar@ti.com>
Subject: Re: [Buildroot] [RFC PATCH 1/2] support/scripts/genimage.sh: support creating a bmap image
Date: Wed, 28 Aug 2024 15:58:21 +0200	[thread overview]
Message-ID: <87ttf47nr6.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20240828154253.206391b0@windsurf> (Thomas Petazzoni's message of "Wed, 28 Aug 2024 15:42:53 +0200")

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 >> I would suggest to drop the gzip step and only create the .bmap files
 >> (which presumably is quite fast?)
 >> 
 >> What do you say?

 > I understand your concern, but compression is also what helps in making
 > those sparse images small.

NIT: No, it is the sparseness (E.G. the holes). Compression in fact
breaks the holes (replaces them by zeros):

truncate -s 1G disk.img
du -hs disk.img
0       disk.img

gzip disk.img
du -hs disk.img.gz
1020K   disk.img.gz

gunzip disk.img.gz
du -hs disk.img
1.0G    disk.img

To transfer a file with holes without losing them you need an archival
format that understands sparse files, E.G. tar -S:

truncate -s 1G disk.img
du -hs disk.img
0       disk.img

tar cfSz disk.tar.gz disk.img
du -hs disk.tar.gz
4.0K    disk.tar.gz

rm disk.img
tar zxf disk.tar.gz
du -hs disk.img
0       disk.img

Notice also that the .tar.gz is a lot smaller than the img.gz


 > Of course, as long as you keep them where Buildroot generated them,
 > they are sparse, so they don't take much space. But as soon as you
 > "distribute" them, they usually loose their sparse-ness, and this is
 > where compressing the image + the bmap metadata file helps in lot in
 > reducing the amount of data.

Correct, unless an archival format supporting sparse files is used, so
if anything we should make a tarball of the images - But that is also
not so simple, E.G.:

- Busybox tar cannot extract sparse tar files
- One tarball for everything or a tarball for each image?
- What compression algorithm and parameters to use?

So it very fast ends up in a very use case specific setup, hence my
suggestion to NOT do it and leave such customizations to a post-image
script.

 > But fair enough, I assume this compression can be done as a custom
 > post-processing step by whoever needs it.

Indeed.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2024-08-28 13:58 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-21  9:53 [Buildroot] [RFC PATCH 0/2] Add support to genimage.sh for creating a bmap image Dario Binacchi
2024-04-21  9:53 ` [Buildroot] [RFC PATCH 1/2] support/scripts/genimage.sh: support " Dario Binacchi
2024-04-23 11:33   ` Gero Schwäricke via buildroot
2024-04-23 12:55     ` Quentin Schulz via buildroot
2024-04-24  7:50       ` Gero Schwäricke via buildroot
2024-04-24  8:06     ` Gero Schwäricke via buildroot
2024-05-10 19:54   ` Thomas Petazzoni via buildroot
2024-05-10 20:17     ` Michael Nazzareno Trimarchi
2024-05-21  5:25       ` Yann E. MORIN
2024-05-21  9:28         ` Michael Nazzareno Trimarchi
2024-05-21 17:44           ` Yann E. MORIN
2024-05-22 15:19             ` Gero Schwäricke via buildroot
2024-05-31  9:47             ` Thomas Petazzoni via buildroot
2024-05-31  9:44         ` Thomas Petazzoni via buildroot
2024-05-20  8:05     ` Dario Binacchi
2024-05-20  9:23       ` Thomas Petazzoni via buildroot
2024-05-21 15:06         ` Dario Binacchi
2024-05-21 20:36         ` Yann E. MORIN
2024-05-22 15:59           ` Gero Schwäricke via buildroot
2024-07-15 14:05   ` Thomas Petazzoni via buildroot
2024-07-15 14:23     ` Arnout Vandecappelle via buildroot
2024-07-15 14:27       ` Thomas Petazzoni via buildroot
2024-07-16  6:16         ` Dario Binacchi
2024-08-27 18:55     ` Peter Korsgaard
2024-08-28 13:42       ` Thomas Petazzoni via buildroot
2024-08-28 13:58         ` Peter Korsgaard [this message]
2024-08-29 21:44           ` Thomas Petazzoni via buildroot
2024-08-30  7:14             ` Peter Korsgaard
2024-08-30 15:29               ` Thomas Petazzoni via buildroot
2024-08-30 15:32                 ` Michael Nazzareno Trimarchi
2024-08-31 13:28                   ` Peter Korsgaard
2024-08-31 13:20                 ` Peter Korsgaard
2024-04-21  9:53 ` [Buildroot] [RFC PATCH 2/2] configs/ti_am62x_sk_defconfig: create the " Dario Binacchi

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=87ttf47nr6.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=X15000177@gmail.com \
    --cc=buildroot@buildroot.org \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=gadiyar@ti.com \
    --cc=linux-amarula@amarulasolutions.com \
    --cc=michael@amarulasolutions.com \
    --cc=thomas.petazzoni@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.