Version Control capabilities plus two small unrelated questions

Version Control capabilities plus two small unrelated questions

[BP25]

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.

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)?

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."

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.

  Please CC or BCC me because I'm not subscribed ro the mailing list.

Re: Version Control capabilities plus two small unrelated questions

[BP25]

Note that when I use the word "snapshotted" by saying snapshotted file 
or snapshotted version of a file, I mean both "A: file that is included 
in the snapshot of a certain volume", and "B: file that was individually 
snapshotted to save a version of it". In fact I think that, if 
individual-file versioning is indeed possible as the first part of my 
question asks, then taking meaning A: or taking meaning B: is irrelevant 
because the code would be essentially the same.

Re: Version Control capabilities plus two small unrelated questions

[Kent Overstreet]

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.

Re: Version Control capabilities plus two small unrelated questions

[BP25]

Dear Kent,
Such an honour to receive your reply! For the sake of simplicity assume 
that I'm just interested in snapshotting individual files. Usecase: 
because I add the snapshot command as hook before saving any file I 
edit. This assumption excludes any discussion about recursive snapshots.

On 26.12.2025 18:09, Kent Overstreet wrote:
> 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?

https://www.gnu.org/philosophy/stallman-kth.en.html starting from 
"Features that I believe must be added include: Version numbers" until 
"Another thing, that isn't a user visible feature and is certainly 
compatible to put in, is failsafeness in the file system."

>> 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.

Rather than having to promote files to subvolumes and then snapshotting 
them, I'd rather allow making snapshots any individual file directly. 
Just because any file should be ready by default to be versioned. 
Sometimes I do wanna follow history at the outer subvolume level; but 
most times I wanna focus on the timeline of this specific file and even 
if snapshotting the outer volume achieves this in practical terms, 
conceptually I would say the two procedures serve distinct purposes.

> 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.

I think that in view of the assumption at the beginning of this email, 
we can disregard for the moment any notion of nestedness and of shared 
histories.
> 
>> 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.

I asked this on the Guix mailing list. My understanding of your sentence 
is that you're not aware of any difficult obstruction to make it work.

> 
>> 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.

Thanks for explaining this.

I appreciate you reading my messages Kent.

Re: Version Control capabilities plus two small unrelated questions

[Franz Schultz]

I'm also interested in such version control design within the FS where 
you save the current version of a file and then are able to access the 
timeline of all such saved versions.

> 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)?