Re: Avoid to produce the bmap stuff that double the size

["Roberto A. Foglietta" <roberto.foglietta@gmail.com>]

Il giorno mar 4 ott 2022 alle ore 08:00 Jan Kiszka
<jan.kiszka@siemens.com> ha scritto:
>
> On 04.10.22 07:46, Roberto A. Foglietta wrote:
> > Hi all,
> >
> > for small footprint embedded system having a bmap is a must and do not
> > overload the drive but when ISAR is used to build 9.3 GB images, then
> > the bmap stuff is useless, redundant and takes precious saving space. I
> > can remove but I wish not produce it in first place:
> >
> > $ find build/tmp/deploy/ -name \*wic\*
> > build/tmp/deploy/images/debx86/eval-image-debian-bullseye-debx86.wic
> > build/tmp/deploy/images/debx86/eval-image-debian-bullseye-debx86.wic.p2
> > build/tmp/deploy/images/debx86/eval-image-debian-bullseye-debx86.wic.bmap
> > build/tmp/deploy/images/debx86/eval-image-debian-bullseye-debx86.wic.p1
> >
>
> I don't think you understood how bmap works and what relates to it. Only
> the .bmap file comes from it. And if that is helpful or not depends on
> how sparse the image is, not how large. But even with a fully populated
> image, bmaptool trumps dd for other reasons.
>
> The listed partition files relate to the discussion in
> https://groups.google.com/g/isar-users/c/LtjoygRabns/m/YZsK6S6vCwAJ.

$ file eval-image-debian-bullseye-debx86.wic.p?
eval-image-debian-bullseye-debx86.wic.p1: DOS/MBR boot sector, code
offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, reserved sectors
4, root entries 512, Media descriptor 0xf8, sectors/FAT 104,
sectors/track 32, heads 8, sectors 106688 (volumes > 32 MB), serial
number 0xc2d97979, label: "efi        ", FAT (16 bit)
eval-image-debian-bullseye-debx86.wic.p2: Linux rev 1.0 ext4
filesystem data, UUID=0e80e944-2eda-43e0-91e1-3b2e163f22cc, volume
name "rootfs" (extents) (64bit) (large files) (huge files)

Dear Jan,

 you are right because despite knowing bmap, there was some kind of
confusion in my question: I mixed up the use of bmap with the creation
/ deletion of the partitions.

 The main point was: I am using ISAR to develop a set of recipes not
for embedded so I do 100 large builds and 1 transfer. Under my PoV, I
like tools like bmap but I am more concerned in speed-up the build.

 For example - supposing that those using ISAR to make a build and
transfer it are 1.000 while those using ISAR to develop recipes are 50
- the most value still stays in speed-up the build rather than the
transfer.

 Especially because those who use ISAR for developing a set of
recipes, are who they are contributing to its development.

 Considering the question and the answers received, I noticed that

 - Jan was focused on technical aspects
 - Felix on the practical aspects like saving space
 - I was pointing out to the value

 The value of a technical tool in order to do certain optimisations
rather than others: fast build vs saving disk space vs transfer speed.

 Confusion is a very bad destinationation but a very good starting point... :-)

 Best regards, R-

 P.S.: the google mail allows the text-only just by the web interface
while the Android application uses HTML always. No, I am writing from
home and I use the web browser.