From: Goffredo Baroncelli <kreijack@libero.it>
To: Remi Gauvin <remi@georgianit.com>, Roman Mamedov <rm@romanrm.net>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: WG: How to properly setup for snapshots
Date: Mon, 21 Dec 2020 21:14:16 +0100 [thread overview]
Message-ID: <de2abd3d-1306-59b3-2ed6-23f03fc443df@libero.it> (raw)
In-Reply-To: <108a3254-f120-b5fe-2b7f-f363cbe34158@georgianit.com>
On 12/21/20 7:14 PM, Remi Gauvin wrote:
> On 2020-12-21 12:37 p.m., Roman Mamedov wrote:
>
>>
>> As such there's no benefit in storing snapshots "inside" a subvolume. There's
>> not much of the "inside". Might as well just create a regular directory for
>> that -- and with less potential for confusion.
>
> Maybe I was complicating things for a baby step primer,, but there *are*
> very good benefits to putting snapshots in a subvolume. That subvolume
> can be moved into other subvolumes, A directory that contains ro
> snapshots can not.
A subvolume can be moved everywhere with a simple 'mv' command.
$ btrfs sub crea sub1
Create subvolume './sub1'
$ btrfs sub crea sub2
Create subvolume './sub2'
$ btrfs sub crea sub1/sub11
Create subvolume 'sub1/sub11'
$ btrfs sub crea sub1/sub12
Create subvolume 'sub1/sub12'
$ mv sub1 sub2/
$ find sub2/
sub2/
sub2/sub1
sub2/sub1/sub12
sub2/sub1/sub11
>
> This will not matter if your only subvolume is the filesystem root, but
> if things were later be subdivided into other subvolumes, it will make
> things much quicker and easier to be able to move the .my_snapshots
> subvolume.
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2020-12-21 20:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM9P191MB165033908B55F8312178D90AE2CB0@AM9P191MB1650.EURP191.PROD.OUTLOOK.COM>
2020-12-21 16:11 ` WG: How to properly setup for snapshots Claudius Ellsel
2020-12-21 17:05 ` Remi Gauvin
2020-12-21 17:37 ` Roman Mamedov
2020-12-21 18:14 ` Remi Gauvin
2020-12-21 20:14 ` Goffredo Baroncelli [this message]
2020-12-21 20:27 ` Remi Gauvin
2020-12-21 20:52 ` Goffredo Baroncelli
2020-12-21 18:26 ` Andrei Borzenkov
2020-12-21 18:35 ` AW: " Claudius Ellsel
2020-12-21 18:40 ` Andrei Borzenkov
2020-12-21 20:51 ` AW: " Claudius Ellsel
2021-01-06 20:07 ` Ulli Horlacher
2020-12-21 20:24 ` WG: " Goffredo Baroncelli
2020-12-21 18:04 ` AW: " Claudius Ellsel
2020-12-21 18:32 ` Remi Gauvin
2020-12-21 18:39 ` AW: " Claudius Ellsel
2020-12-21 20:45 ` Claudius Ellsel
2020-12-21 23:33 ` Graham Cobb
2020-12-22 15:19 ` AW: " Claudius Ellsel
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=de2abd3d-1306-59b3-2ed6-23f03fc443df@libero.it \
--to=kreijack@libero.it \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=remi@georgianit.com \
--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