All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.