3 ms·
Cool idea! Is there any particular reason to use SquashFS via FUSE instead of via the Linux kernel driver? Slightly related: we also recently switched to Squas
by secure 8y ago
Cool idea! Is there any particular reason to use SquashFS via FUSE instead of via the Linux kernel driver?
Slightly related: we also recently switched to SquashFS for the gokrazy.org’s root file systems.
If you’re curious about how SquashFS works under the hood, check out https://github.com/gokrazy/internal/blob/master/squashfs/writer.go https://github.com/gokrazy/internal/blob/master/squashfs/wri.... I also intend to publish a poster about it at some point.
- ctur 8y agoWe actually started with using "real" squashfs files. This had three main disadvantages: - We had to maintain our own setuid executable to perform the loopback setup and mount (rather than relying on the far more tested and secure open source fusermount setuid binary that all FUSE file systems rely on) - Getting loopback devices to behave inside of containers (generally cgroup and mount namespace containers) was a little tricky at times in some of our environments - We didn't want to have a huge number of extra loopback devices on every host in our fleet In fact, after implementing the loopback-based filesystem version, we almost abandoned XAR as the downside of the security considerations and in-container behavior wasn't ideal. The open source squashfuse FUSE filesystem really is what made it possible. Another side benefit is we could iterate far faster with squashfuse -- this let us fix some performance issues, add idle unmounting, and implement zstd-based squashfs files, and then deploy that to our fleet, faster than we could deploy a kernel to 100% of hosts.
- secure 8y agoThanks, makes sense!