From: Chester <somethingsome2000@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: snapshot strange behaviour
Date: Sun, 23 Jan 2011 13:02:01 -0600 [thread overview]
Message-ID: <AANLkTi=An_0pxbOkXeqi+BSfxZH+Ne3-iVVh7a9_uH_j@mail.gmail.com> (raw)
In-Reply-To: <4D3C6D23.106@libero.it>
Also, btrfs already has a utility to scan for subvolumes in a directory
btrfs subvolume list /path
On Sun, Jan 23, 2011 at 12:02 PM, Goffredo Baroncelli
<kreijack@libero.it> wrote:
> 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 subvolu=
mes?
>>>
>>> It is the intended behavior. The snapshotting is not recursive abou=
t
>>> subvolumes. If you snapshot a subvolume which contains another one,=
you
>>> got only the content of the first subvolume. The directory "x/b" wh=
ich
>>> 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 le=
ast
>> print a warning. Otherwise it is very inconvenient for the user, hav=
ing 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 roo=
tfs
> 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
>
>> Lubos
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrf=
s" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>> .
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-01-23 19:02 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 [this message]
2011-01-23 20:06 ` Lubos Kolouch
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='AANLkTi=An_0pxbOkXeqi+BSfxZH+Ne3-iVVh7a9_uH_j@mail.gmail.com' \
--to=somethingsome2000@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).