On Wed, Dec 24, 2025 at 04:02:01PM +0000, BP25 wrote: > Hello, would someone kindly advise whether bcachefs supports file > versioning, somewhat in the spirit of Stallman (lecture at KTH Sweden in > 1986) where files are individually versioned (as opposed as taking snapshots > of entire volumes) but the versions are not just ordinary distinct files, > they are hidden files connected with each other.
Got a link to the lecture? > In particular is there a standard way to 'follow' the same file along its > snapshotted versions? Say, ask bcachefs to return the list of snapshotted > versions by giving input this or that file in the current version of the > filesystem? Note that if such file was deleted and another with the same > name created I don't want that new file also to show up. And related > question, is there any command that would list the snapshotted files which > have no corresponding in the current version of the file system (for example > because I deleted such file after having snapshotted it)? Snapshotting is only at subvolume granularity, and right now there's no way to create a subvolume that points to a single file. There's no reason that couldn't be added, but if you do that you'll probably still want to be able to follow history at the outer subvolume level; we don't have proper support for recursive subvolumes. History between different subvolumes is completely distinct; I could see us wanting to support some sort of concept of "nested histories", but that'd be a project for down the road. > First small unrelated question: do you confirm that standard Guix is > currently incompatible with bcachefs as root filesystem and is there any > plan to patch Guix so that it's possible (with standard Guix installation)? > Note: "Currently Guix System only supports ext4, btrfs, JFS, F2FS, and XFS > file systems. In particular, code that reads file system UUIDs and labels > only works for these file system types." I haven't seen any incompatibilities reported. Util-linux supports bcachefs and has for ages, so I'm not sure what that would be. > Why does the generation number in bcachefs snapshots starts from U32max and > goes down, instead of the naive start from 0 and goes up? There must be some > strong conceptual reason for doing the first because I see already a few > small conceptual reasons to do the second. It's because of the way snapshot lookups work. When we do a lookup within a subvolume, we first get the subvolume's current snapshot ID, and then we do a lookup for SPOS(inode, offset, snapshot). We want either the key for snapshot, or the closest descendent; allocating snapshot IDs in reverse order means that ancestors come after our search key, not before, and this is important because iterating forwards is much cheaper than iterating backwards.
