Hi There,
Is there any way to speed up the flash time of a .mender image? I’ve recently increased the size of our root file systems from about 800MB to 6.5GB, and started using bmap-tools to speed up the flash of the SD card (I can flash a full ~16GB SDIMG image file in a short few minutes).
However, increasing the size of the root file system has had a dramatic negative impact on the mender upgrade time (even though the .mender file size is still about 70MB). Is there anything which can be done for this? Perhaps some way of incorporating the use of bmap file into the mender image flash?
Cheers,
Donal
This has been discussed a bit in our team before, and the conclusion was
that this will be much easier to implement using an update module, which
was why we have focused our efforts on developing that first. It is
nearing completion and will be in the upcoming Mender 2.0.0.
Writing such an update module would be simple, you’d just receive a pipe
you stream the bmap file from, and then apply it to the filesystem. See
the update modules spec
https://github.com/mendersoftware/mender/blob/35f539c236a796a6565a3bedd192b23f3ce556aa/Documentation/update-modules-v3-file-api.md
for more information on this.
Hi Kristian,
Thank you for the info. Do you know why the flash takes so long? Is it just the write time for the SD card or is there a bottleneck somewhere else (perhaps mender)?
Cheers,
Donal
The reason it is taking long is that your file-system image is 6.5GB and it is probably 99 % zeroes because the compressed artifact is only 70 MB.
The mender client currently is not able to handle sparse files, so it needs to write the whole 6.5GB of data even if it just zeroes.
One optimization that I normally do to speed up things (taking your sizes as example) is to still allocate the partition size to 6.5GB but the file system size I make relative to actual content size + 15 % extra free space.
That way the mender client will only write the actual content + a relative number of zero data for free space.
1 Like
@Mirzak, do you have any links/notes on how to make that working?
I typically do this in Yocto, e.g in the local.conf
# Explicitly set this to zero as it might sneak in depending on what we include.
IMAGE_ROOTFS_EXTRA_SPACE = "0"
#
# # If we set this to zero we rely completely on IMAGE_OVERHEAD_FACTOR.
IMAGE_ROOTFS_SIZE = "0"
#
# # This will make sure that we a relative amount of extra free space on rootfs.
# # 1.2 means that we will have 20 % extra free space added.
IMAGE_OVERHEAD_FACTOR = "1.2"
1 Like
Alright, so then you flash an “old” image, which has bigger size partitions, and then update using mender to a smaller update?
Thank you for the info. Do you know why the flash takes so long? Is it just the write time for the SD card or is there a bottleneck somewhere else (perhaps mender)?
Also, we know about one bottleneck, due to small write buffers, which has already been fixed (1a0d2168fddc981212b78e172d4a18f498f04104 in the mender repository, the forum won’t let me link to it for some reason), but not released yet.
1 Like
Struggling to find that commit, is there a commit description I could search for?
Struggling to find that commit, is there a commit description I could search for?
1 Like
How does the OS know to ignore the data behind the actual newly flashed data?
Is it because the partition was made small and just happens to live in a somewhat larger partition?
Is that going OK all the time?
How does the OS know to ignore the data behind the actual newly flashed data?
Is it because the partition was made small and just happens to live in a somewhat larger partition?
Well there is a distinction between partition and filesystem, and they normally do not have any information about the other. The partition size never changes, but you do have the possibility to change the filesystem image size.
What you flash with Mender is a filesystem image on to a partition, the filesystem image holds all the necessary information (size etc…) and this is what the OS interacts with. Mender will make the check if your filesystem is larger then the allocated partition, but there are no problems if it is smaller.
1 Like
I just saw this thread and it fit a question I just had: I’m on zeus currently and I saw the mender artifact comes with a mender.bmap file. Thus, is the information in this thread outdated? Can I use the bmaptool to speed up flashing an artifact to the inactive partition?
No, the bmap file won’t work as it covers the entire artifact including the metadata. It should probably be removed. I believe the current image writing code is fairly well optimized when writing redundant data. @kacf will know more.
1 Like
Are we certain that .mender.bmap is not just for a single partition as mine says its image size is 76.3MiB compared to my .sdimg.bmap file which has image size of 3.5GiB?
It definitely is just for a single image, but it’s generated against the .mender file including the metadata rather than the binary image that is wrapped in the .mender file.
Drew
1 Like
Yes, it is optimized, but not as optimized as bmap. Bmap requires knowledge of filesystem internals, whereas Mender writes as optimized as is possible without knowing about filesystem internals. This means it reads the blocks first (which is faster than writing), and only writes those that have changed. Bmap on the other hand, omits writing entire blocks if they are part of the free space on the filesystem, even if those blocks differ from those in the artifact.
1 Like