From: Lubos Kolouch <lubos.kolouch@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: snapshot strange behaviour
Date: Sun, 23 Jan 2011 15:05:12 +0000 (UTC) [thread overview]
Message-ID: <ihhg37$8qj$1@dough.gmane.org> (raw)
In-Reply-To: 4D3C1C49.8040104@libero.it
Goffredo Baroncelli, Sun, 23 Jan 2011 13:17:13 +0100:
> Hi Lubos,
>
> On 01/23/2011 08:17 AM, Lubos Kolouch wrote:
>> Hello,
>>
>> During doing backups I found strange behaviour... 2.6.37, latest btrfs-
>> progs from git
>>
>> nbgentoo ~ # btrfs subv crea a
>> Create subvolume './a'
>> nbgentoo ~ # cd a
>> nbgentoo a # btrfs subv crea b
>> Create subvolume './b'
>> nbgentoo a # touch b/file
>> nbgentoo a # ls -l b/
>> total 0
>> -rw-r--r-- 1 root root 0 Jan 23 08:14 file nbgentoo a # cd ..
>> nbgentoo ~ # btrfs subv snap a x
>> Create a snapshot of 'a' in './x'
>> nbgentoo ~ # ls -l x/b/
>> total 0
>>
>> and also
>>
>> nbgentoo ~ # cd x/
>> nbgentoo x # btrfs subv dele b
>> ERROR: 'b' is not a subvolume
>>
>> 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...
Lubos
next prev parent reply other threads:[~2011-01-23 15:05 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 [this message]
2011-01-23 18:02 ` Goffredo Baroncelli
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='ihhg37$8qj$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 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.