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.
>>
>>
next prev parent 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