https://www.scrivano.org/tags/composefs/ Recent content in Composefs on *scratch* Hugo en Fri, 10 Jul 2026 10:41:24 +0200 https://www.scrivano.org/posts/2026-07-10-composefs-image-locking-with-flock/ Fri, 10 Jul 2026 10:00:00 +0200 https://www.scrivano.org/posts/2026-07-10-composefs-image-locking-with-flock/ <p>For the last couple of weeks, I&rsquo;ve been working on garbage collection for composefs repositories. A composefs repository is a content-addressed object store, and it needs a garbage collector to reclaim space from images that are no longer referenced. The hard part is deciding what &ldquo;referenced&rdquo; actually means when an image has no ref in the repository but is mounted somewhere, possibly from another process, possibly in a different mount namespace, possibly by the running system itself. On <a href="https://github.com/composefs/composefs-rs/issues/346">composefs-rs#346</a> was suggested to use <code>flock()</code> on the EROFS backing file. Mounters take a shared lock, the GC probes with an exclusive one, and if the exclusive lock fails, the image is still in use.</p> https://www.scrivano.org/posts/2026-06-05-sealing-with-composefs/ Fri, 05 Jun 2026 08:00:00 +0000 https://www.scrivano.org/posts/2026-06-05-sealing-with-composefs/ <p>Composefs achieves whole-filesystem integrity verification through <em>image sealing</em>: a single cryptographic digest authenticates an entire filesystem, covering both file contents and metadata (directory structure, permissions, ownership, symlinks, and xattrs). This goes further than fs-verity alone, which can only verify individual file contents, and avoids the fixed-partition requirement of dm-verity. The mechanism combines an EROFS image for metadata, a content-addressed object store for file data, and overlayfs with <code>verity=require</code> to enforce integrity checks on every file access at the kernel level.</p> https://www.scrivano.org/posts/2021-10-26-compose-fs/ Tue, 26 Oct 2021 16:02:56 +0200 https://www.scrivano.org/posts/2021-10-26-compose-fs/ <p>For the last couple of weeks, I&rsquo;ve been playing on a PoC implementation of a file system for the Linux kernel. The goal is to address a fundamental limitation in how container images are stored: the existing overlay model deduplicates at the layer level, but once you want per-file deduplication — so that identical files across different images share a single copy on disk and in the page cache — the current architecture gets in the way and requires awkward workarounds involving hard links or filesystem-specific reflinks.</p>