Snapshots of individual files

Snapshots of individual files

[BP25]

Hello,
Can any of you guys help me understand why it hasn't been made possible 
to snapshot individual files? Because technically it's trivial to 
implement therefore I suspect there must be some abstract reason... The 
only thing I can think of is the case where some file which was 
snapshotted is then deleted hence there is no way to 'select such file' 
and ask btrfs for the snapshotted versions... but even in this case I 
see no problem: either the convention is that when you delete a file 
then all snapshots of such individual file are also deleted, or better 
there is a command that shows all files who have been deleted but have 
have been snapshotted in the past.
Any ideas?
Please CC or BCC me cause I'm not subscribed.

Re: Snapshots of individual files

[Roman Mamedov]

On Tue, 23 Dec 2025 00:43:25 +0000
BP25 <bp25@posteo.net> wrote:

> Hello,
> Can any of you guys help me understand why it hasn't been made possible 
> to snapshot individual files? Because technically it's trivial to 
> implement therefore I suspect there must be some abstract reason... The 
> only thing I can think of is the case where some file which was 
> snapshotted is then deleted hence there is no way to 'select such file' 
> and ask btrfs for the snapshotted versions... but even in this case I 
> see no problem: either the convention is that when you delete a file 
> then all snapshots of such individual file are also deleted, or better 
> there is a command that shows all files who have been deleted but have 
> have been snapshotted in the past.
> Any ideas?
> Please CC or BCC me cause I'm not subscribed.

You can make "snapshots" of a file with:

  cp -a --reflink filename filename.snap

from what I tested this appears to be atomic (entire file is reflinked at
once), someone might correct me if I'm wrong.

Works on modern XFS too.

-- 
With respect,
Roman

Re: Snapshots of individual files

[BP25]

Dear Roman,
Thanks for your informative answer. But this is precisely the wrong 
solution: btrfs snapshots shouldn't and in fact don't clutter the 
filesystem with previous versions of the files because such ghost 
versions materialise when the snapshot is mounted. In my original 
message I seek for the analogous behaviour. Also I don't want to 
generate more and more copies...

On 23.12.2025 08:56, Roman Mamedov wrote:
> On Tue, 23 Dec 2025 00:43:25 +0000 wrote:
> 
>> Hello,
>> Can any of you guys help me understand why it hasn't been made 
>> possible
>> to snapshot individual files? Because technically it's trivial to
>> implement therefore I suspect there must be some abstract reason... 
>> The
>> only thing I can think of is the case where some file which was
>> snapshotted is then deleted hence there is no way to 'select such 
>> file'
>> and ask btrfs for the snapshotted versions... but even in this case I
>> see no problem: either the convention is that when you delete a file
>> then all snapshots of such individual file are also deleted, or better
>> there is a command that shows all files who have been deleted but have
>> have been snapshotted in the past.
>> Any ideas?
>> Please CC or BCC me cause I'm not subscribed.
> 
> You can make "snapshots" of a file with:
> 
>   cp -a --reflink filename filename.snap
> 
> from what I tested this appears to be atomic (entire file is reflinked 
> at
> once), someone might correct me if I'm wrong.
> 
> Works on modern XFS too.

Re: Snapshots of individual files

[Andrei Borzenkov]

On Tue, Dec 23, 2025 at 1:26 PM BP25 <bp25@posteo.net> wrote:
>
> Dear Roman,
> Thanks for your informative answer. But this is precisely the wrong
> solution: btrfs snapshots shouldn't and in fact don't clutter the
> filesystem with previous versions of the files because such ghost
> versions materialise when the snapshot is mounted.

That depends on your subvolume layout. Nothing forces you to place the
file copy into the same directory as the source either.

> In my original
> message I seek for the analogous behaviour.

It is exactly analogous.

> Also I don't want to
> generate more and more copies...
>

To reference a snapshot (be it subvolume or file) it must have a name
which you must provide. To create a snapshot with a given name in some
location this location must be accessible at the time the snapshot is
being created. As long as this location remains accessible its content
remains accessible. There is no difference between file and subvolume.

If you complain that you cannot mount a single file outside of the
default subvolume and can only mount subvolumes - it is an entirely
different question which is unrelated to how this file was created.

> On 23.12.2025 08:56, Roman Mamedov wrote:
> > On Tue, 23 Dec 2025 00:43:25 +0000 wrote:
> >
> >> Hello,
> >> Can any of you guys help me understand why it hasn't been made
> >> possible
> >> to snapshot individual files? Because technically it's trivial to
> >> implement therefore I suspect there must be some abstract reason...
> >> The
> >> only thing I can think of is the case where some file which was
> >> snapshotted is then deleted hence there is no way to 'select such
> >> file'
> >> and ask btrfs for the snapshotted versions... but even in this case I
> >> see no problem: either the convention is that when you delete a file
> >> then all snapshots of such individual file are also deleted, or better
> >> there is a command that shows all files who have been deleted but have
> >> have been snapshotted in the past.
> >> Any ideas?
> >> Please CC or BCC me cause I'm not subscribed.
> >
> > You can make "snapshots" of a file with:
> >
> >   cp -a --reflink filename filename.snap
> >
> > from what I tested this appears to be atomic (entire file is reflinked
> > at
> > once), someone might correct me if I'm wrong.
> >
> > Works on modern XFS too.
>
>

Re: Snapshots of individual files

[BP25]

Thanks for this message and the clarifications. The key was your note 
that I can put the copy in the snapshots folder: is this correct? if yes 
then Roman I think your answer indeed addresses my original question, 
and I misspoke in my previous email, sorry. Is there a standard way to 
'follow' the same file along its snapshotted versions? Say, ask btrfs 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)? Please CC or BCC me. Many thanks.

On 23.12.2025 12:19, Andrei Borzenkov wrote:
> On Tue, Dec 23, 2025 at 1:26 PM BP25 wrote:
>> 
>> Dear Roman,
>> Thanks for your informative answer. But this is precisely the wrong
>> solution: btrfs snapshots shouldn't and in fact don't clutter the
>> filesystem with previous versions of the files because such ghost
>> versions materialise when the snapshot is mounted.
> 
> That depends on your subvolume layout. Nothing forces you to place the
> file copy into the same directory as the source either.
>> In my original
>> message I seek for the analogous behaviour.
> 
> It is exactly analogous.
> 
>> Also I don't want to
>> generate more and more copies...
>> 
> 
> To reference a snapshot (be it subvolume or file) it must have a name
> which you must provide. To create a snapshot with a given name in some
> location this location must be accessible at the time the snapshot is
> being created. As long as this location remains accessible its content
> remains accessible. There is no difference between file and subvolume.
> 
> If you complain that you cannot mount a single file outside of the
> default subvolume and can only mount subvolumes - it is an entirely
> different question which is unrelated to how this file was created.

Sure, I'm not asking about this now.

> 
>> On 23.12.2025 08:56, Roman Mamedov wrote:
>> > On Tue, 23 Dec 2025 00:43:25 +0000 wrote:
>> >
>> >> Hello,
>> >> Can any of you guys help me understand why it hasn't been made
>> >> possible
>> >> to snapshot individual files? Because technically it's trivial to
>> >> implement therefore I suspect there must be some abstract reason...
>> >> The
>> >> only thing I can think of is the case where some file which was
>> >> snapshotted is then deleted hence there is no way to 'select such
>> >> file'
>> >> and ask btrfs for the snapshotted versions... but even in this case I
>> >> see no problem: either the convention is that when you delete a file
>> >> then all snapshots of such individual file are also deleted, or better
>> >> there is a command that shows all files who have been deleted but have
>> >> have been snapshotted in the past.
>> >> Any ideas?
>> >> Please CC or BCC me cause I'm not subscribed.
>> >
>> > You can make "snapshots" of a file with:
>> >
>> >   cp -a --reflink filename filename.snap
>> >
>> > from what I tested this appears to be atomic (entire file is reflinked
>> > at
>> > once), someone might correct me if I'm wrong.
>> >
>> > Works on modern XFS too.
>> 
>> 

Re: Snapshots of individual files

[Roman Mamedov]

On Tue, 23 Dec 2025 12:08:04 +0000
BP25 <bp25@posteo.net> wrote:

> Is there a standard way to 'follow' the same file along its snapshotted
> versions? Say, ask btrfs 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)?

There is none of that :)

I put "snapshotted" files in quotes for a reason, it is not a snapshot and
there is no snapshot tree or inheritance.

It is a lightweight instant copy, which lets you to very quickly and
efficiently hold on to states of that file as it was at various points in the
past, if you want to. Where you put it, or which scenarios you envision, is up
to you.

I use this to backup running file-backed VMs, first reflink the image to a
file, then can safely start to gzip that file or copy it to a remote host. The
running VM otherwise would ruin the consistency, with ongoing writes to
its image halfway in that process.

Cool part is that like the snapshots, this is done instantly and consumes no
extra disk space, only the changed bits in the "current" file will. Or you can
go ahead and start changing both files at the same time, that too, will only
increase overall space usage by the amount of changed portions.

-- 
With respect,
Roman

Re: Snapshots of individual files

[Andrei Borzenkov]

On Tue, Dec 23, 2025 at 3:08 PM BP25 <bp25@posteo.net> wrote:
>
> Thanks for this message and the clarifications. The key was your note
> that I can put the copy in the snapshots folder: is this correct? if yes
> then Roman I think your answer indeed addresses my original question,
> and I misspoke in my previous email, sorry. Is there a standard way to
> 'follow' the same file along its snapshotted versions? Say, ask btrfs to
> return the list of snapshotted versions by giving input this or that
> file in the current version of the filesystem?

No. From this perspective reflinks are far more inferior to the
subvolume snapshots indeed.

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

Again, no. A file, "snapshotted" with reflinks, is indistinguishable
from the original file.

> Please CC or BCC me. Many thanks.
>
> On 23.12.2025 12:19, Andrei Borzenkov wrote:
> > On Tue, Dec 23, 2025 at 1:26 PM BP25 wrote:
> >>
> >> Dear Roman,
> >> Thanks for your informative answer. But this is precisely the wrong
> >> solution: btrfs snapshots shouldn't and in fact don't clutter the
> >> filesystem with previous versions of the files because such ghost
> >> versions materialise when the snapshot is mounted.
> >
> > That depends on your subvolume layout. Nothing forces you to place the
> > file copy into the same directory as the source either.
> >> In my original
> >> message I seek for the analogous behaviour.
> >
> > It is exactly analogous.
> >
> >> Also I don't want to
> >> generate more and more copies...
> >>
> >
> > To reference a snapshot (be it subvolume or file) it must have a name
> > which you must provide. To create a snapshot with a given name in some
> > location this location must be accessible at the time the snapshot is
> > being created. As long as this location remains accessible its content
> > remains accessible. There is no difference between file and subvolume.
> >
> > If you complain that you cannot mount a single file outside of the
> > default subvolume and can only mount subvolumes - it is an entirely
> > different question which is unrelated to how this file was created.
>
> Sure, I'm not asking about this now.
>
> >
> >> On 23.12.2025 08:56, Roman Mamedov wrote:
> >> > On Tue, 23 Dec 2025 00:43:25 +0000 wrote:
> >> >
> >> >> Hello,
> >> >> Can any of you guys help me understand why it hasn't been made
> >> >> possible
> >> >> to snapshot individual files? Because technically it's trivial to
> >> >> implement therefore I suspect there must be some abstract reason...
> >> >> The
> >> >> only thing I can think of is the case where some file which was
> >> >> snapshotted is then deleted hence there is no way to 'select such
> >> >> file'
> >> >> and ask btrfs for the snapshotted versions... but even in this case I
> >> >> see no problem: either the convention is that when you delete a file
> >> >> then all snapshots of such individual file are also deleted, or better
> >> >> there is a command that shows all files who have been deleted but have
> >> >> have been snapshotted in the past.
> >> >> Any ideas?
> >> >> Please CC or BCC me cause I'm not subscribed.
> >> >
> >> > You can make "snapshots" of a file with:
> >> >
> >> >   cp -a --reflink filename filename.snap
> >> >
> >> > from what I tested this appears to be atomic (entire file is reflinked
> >> > at
> >> > once), someone might correct me if I'm wrong.
> >> >
> >> > Works on modern XFS too.
> >>
> >>