From: Lubos Kolouch <lubos.kolouch@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: snapshot strange behaviour
Date: Sun, 23 Jan 2011 20:06:10 +0000 (UTC) [thread overview]
Message-ID: <ihi1ni$o13$1@dough.gmane.org> (raw)
In-Reply-To: 4D3C6D23.106@libero.it
Goffredo Baroncelli, Sun, 23 Jan 2011 19:02:11 +0100:
> On 01/23/2011 04:05 PM, Lubos Kolouch wrote:
>> Goffredo Baroncelli, Sun, 23 Jan 2011 13:17:13 +0100:
>>
>>> Hi Lubos,
>>>
>>> On 01/23/2011 08:17 AM, Lubos Kolouch wrote:
>>>> Hello,
>
>>>> Is this a bug or intended behaviour and I am missing something
>>>> something? How to snapshot a subvolume, containing another
>>>> subvolumes?
>>>
>>> It is the intended behavior. The snapshotting is not recursive about
>>> subvolumes. If you snapshot a subvolume which contains another one,
>>> you got only the content of the first subvolume. The directory "x/b"
>>> which you see, is not the subvolume "b" snapshotted, but only the
>>> "mount-point" of "b".
>>>
>>>
>> Hi Goffredo,
>>
>> I understand. But then I think btrfs should refuse to do it or at least
>> print a warning. Otherwise it is very inconvenient for the user, having
>> to search for any subvolumes down the tree...
>
>
> Sorry, but I can't agree. To me it seems a reasonable default. There are
> a lot of cases where I would not snapshot a sub-sub-subvolume: my rootfs
> is a subvolume, my home is in another one. I can snapshot, update the
> root fs, then if something goes wrong I can roolback to the old one,
> without affecting my home.
>
> This behavior is strictly related to the btrfs internal.
>
> Any way it is true that this behavior should be highlighted in the
> documentation.
>
> And more, it is possible to add a "-R" flag to snapshot recursively a
> subvolume...
>
> Goffredo
The -R would be nice... two use cases :
1) directory many_small_files under the /home subvolume, that you need
only for a while - it is easier to for example delete it when it is
subvolume as well
2) backups
subvolume backups -> subvolumes 20110122, 20110123, ...
you want to delete backups older than x years -> it is much faster to do
if it is a subvolume as well. But - you may as well want to be able
snapshot or delete the whole backups subvolume.
Lubos
next prev parent reply other threads:[~2011-01-23 20:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-23 7:17 snapshot strange behaviour Lubos Kolouch
2011-01-23 12:17 ` Goffredo Baroncelli
2011-01-23 15:05 ` Lubos Kolouch
2011-01-23 18:02 ` Goffredo Baroncelli
2011-01-23 19:02 ` Chester
2011-01-23 20:06 ` Lubos Kolouch [this message]
2011-01-24 2:01 ` Fajar A. Nugraha
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='ihi1ni$o13$1@dough.gmane.org' \
--to=lubos.kolouch@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).