Offline Updates - SquashFS support request

Technical Support
, , , ,
1

I know offline updates are still in early stages of rollout but I’d like to propose/request support for squashfs images in the next version. We’ve been working with them on TorizonCore 5.7.0 and some aspects are… painful out-of-the-box. The generated update data comprises some 14000 small files which takes well over 30 minutes to extract from e.g. a distributable .tgz , whether it be directly to a USB drive or some internal storage on the SoM itself.

We’ve worked around this by packing its contents in to a SquashFS file and then mounting this directly from the USB drive which results in significanly less overhead and time spent copying data as a part of the process.

Given this seems like a good improvement to the offline update user experience I’d like to suggest it is worth exploring making it the “official” update format - a signed squashfs image of the update with some metadata to allow the update client to recognize it - and a few configuration options to allow the designer to specify e.g. a custom file extension/name to filter when checking media for updates.
This also has the added benefit of passively enabling updates via any channel that can transport a file - for example, in one of our use cases we intend to have a series of networked (without Internet) SoMs where a primary controller will distribute the update to all its connected nodes rather than needing to have a user visit each remote individually with a “magic” usb drive. Each SoM would copy the update to its local (SD) storage, mount it, and remove it when finished.

2

Greetings @bw908,

I’d like to suggest it is worth exploring making it the “official” update format

Just making sure I understand your proposal here. Are you suggesting we use SquashFS as our update medium instead of OSTree? Or are you suggesting we use it as a compliment to OSTree? Or did I just misunderstand you completely?

We’ve worked around this by packing its contents in to a SquashFS file and then mounting this directly from the USB drive which results in significanly less overhead and time spent copying data as a part of the process.

Though from this it sounds like you took the OSTree files, compressed/packaged them into a SquashFS, is that right?

That said generally speaking your issue is that the OSTree files themselves (which is a majority of the files in the offline update Lockbox), are too large and take a while to transfer around, correct? Therefore you’re looking for a way to make these files easier to handle, whether it be by some compression, squashfs, or some other method.

Also as for your use-case when you generate the offline update Lockbox, you then compress it to a tgz archive so that you can distribute it easier, correct? Which then causes the headache for you since it takes a while to then extract from this archive for use.

If I understood this all correctly I can run it by our development team. Though a change like this will take quite some time to discuss and again no guarantees on if or when it will be done.

Best Regards,
Jeremias

3

Just making sure I understand your proposal here. Are you suggesting we use SquashFS as our update medium instead of OSTree? Or are you suggesting we use it as a compliment to OSTree? Or did I just misunderstand you completely?

I’m proposing it be used as a packaging/archiving means for the OSTree output to produce a “single file” update - think of it like creating a .tgz, (it’s a compressed filesystem) but one that can be directly mounted on the target device without needing to be extracted somewhere first. SquashFS is essentially designed exactly for this sort of use case.

Though from this it sounds like you took the OSTree files, compressed/packaged them into a SquashFS, is that right?

Correct, I have a post-lockbox create step that creates a .squashfs file containing the contents of the update folder made by torizoncore-builder.

That said generally speaking your issue is that the OSTree files themselves (which is a majority of the files in the offline update Lockbox), are too large and take a while to transfer around, correct? Therefore you’re looking for a way to make these files easier to handle, whether it be by some compression, squashfs, or some other method.

This is correct, the loose files are not manageable for distribution to end customers in any practical sense. The files themselves are not large (apart from a small handful which are also large on the target filesystem) But we’d be laughed out of the room if we proposed our customers download several thousand (or even hundred) files individually to assemble and perform an update. (I’m being a little tongue-in-cheek here as I don’t think this was how offline update was intended to be used, but it certainly seems like a strange implementation to have it be the “default” output and leave dealing with managing these output files up to the developer)

Also as for your use-case when you generate the offline update Lockbox, you then compress it to a tgz archive so that you can distribute it easier, correct? Which then causes the headache for you since it takes a while to then extract from this archive for use.

Yes, we previously tried using a tar archive, but the sheer number of small files it contains leads to terrible performance when the archive contents are extracted (whether it be onto a USB drive directly by the user, or onto internal storage by the SoM itself). In both cases I tested, it was the better part of an hour, and I believe the primary cause here is just the filesystem overhead of getting those entries into its records. (in other words, copying 10000 1K files is excruciatingly slow, whereas a single 10MB file is copied almost instantly)

4

Okay I think I have the full picture on your use-case, issue, and request here. I’ll go ahead and bring it to our team, but as I said before I can’t really make any guarantees on any timelines or actions we will take. Initially it will just be a request to consider the idea.

That is to say for the time being you’ll probably have to stick with your workaround you have here.

Best Regards,
Jeremias

1 Like
5

Yes, understood - the workaround we came up with just makes so much sense to me I figured I’d suggest it as the official solution :slight_smile: