Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: BP25 <bp25@posteo.net>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: Roman Mamedov <rm@romanrm.net>,
	Linux btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Snapshots of individual files
Date: Tue, 23 Dec 2025 12:08:04 +0000	[thread overview]
Message-ID: <282168f52d13e55e466c2fd079a246de@posteo.net> (raw)
In-Reply-To: <CAA91j0XJNaGMyxJegYr7kr+JDg1RRFv9mOcGkwmoDKKk5dDp8g@mail.gmail.com>

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

  reply	other threads:[~2025-12-23 12:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-23  0:43 Snapshots of individual files BP25
2025-12-23  7:56 ` Roman Mamedov
2025-12-23 10:26   ` BP25
2025-12-23 11:19     ` Andrei Borzenkov
2025-12-23 12:08       ` BP25 [this message]
2025-12-23 12:27         ` Roman Mamedov
2025-12-23 12:48         ` Andrei Borzenkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=282168f52d13e55e466c2fd079a246de@posteo.net \
    --to=bp25@posteo.net \
    --cc=arvidjaar@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rm@romanrm.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox