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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.