Re: Version Control capabilities plus two small unrelated questions

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.