From: Goffredo Baroncelli <kreijack@libero.it>
To: Lubos Kolouch <lubos.kolouch@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: snapshot strange behaviour
Date: Sun, 23 Jan 2011 19:02:11 +0100 [thread overview]
Message-ID: <4D3C6D23.106@libero.it> (raw)
In-Reply-To: <ihhg37$8qj$1@dough.gmane.org>
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
> Lubos
>
> --
> 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 18: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 [this message]
2011-01-23 19:02 ` Chester
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=4D3C6D23.106@libero.it \
--to=kreijack@libero.it \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lubos.kolouch@gmail.com \
/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).