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.
