Re: Version Control capabilities plus two small unrelated questions

[BP25 <bp25@posteo.net>]

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.