All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: linux-btrfs@vger.kernel.org
Subject: Re: delete recursivly subvolumes?
Date: Fri, 5 Jul 2019 20:02:16 +0000	[thread overview]
Message-ID: <20190705200216.GR32479@carfax.org.uk> (raw)
In-Reply-To: <20190705195639.GD23600@tik.uni-stuttgart.de>

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Fri, Jul 05, 2019 at 09:56:39PM +0200, Ulli Horlacher wrote:
> On Fri 2019-07-05 (19:51), Hugo Mills wrote:
> 
> > > Is there a command/script/whatever to snapshot (copy) a subvolume which
> > > contains (somewhere) other subvolumes?
> > > 
> > > Example:
> > > 
> > > root@xerus:/test# btrfs_subvolume_list /test/ | grep /tmp
> > > /test/tmp
> > > /test/tmp/xx/ss1
> > > /test/tmp/xx/ss2
> > > /test/tmp/xx/ss3
> > > 
> > > I want to have (with one command):
> > > 
> > > /test/tmp --> /test/tmp2
> > > /test/tmp/xx/ss1 --> /test/tmp2/xx/ss1
> > > /test/tmp/xx/ss2 --> /test/tmp2/xx/ss2
> > > /test/tmp/xx/ss3 --> /test/tmp2/xx/ss3
> > 
> >    Remember that this isn't quite so useful, because you can't make
> > read-only snapshots in that structure.
> 
> ss1 ss2 and ss3 are indeed read-only snapshots!
> Of course they do not contain other subvolumes.

   What I'm saying is that you can't make a RO snapshot of test/tmp to
test/tmp2 and have your RO snapshots of ss1-3 in place within it.

   (OK, you could make the snapshot RW initially, snapshot the others
into place and then force it RO, but then you've just broken
send/receive on tmp2).

> >    Generally, I'd recommend not having nested subvols at all, but to
> > put every subvol independently, and mount them into the places you
> > want them to be. That avoids a lot of the issues of nested subvols,
> > such as the ones you're trying to deal with here.
> 
> *I* do it this way from the very beginning :-)
> But I have *users* with *strange* ideas :-}
> 
> I need to handle their data.

   That makes it more awkward. :(

   Hugo.

-- 
Hugo Mills             | "You know, the British have always been nice to mad
hugo@... carfax.org.uk | people."
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                         Laura Jesson, Brief Encounter

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2019-07-05 20:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05 19:39 delete recursivly subvolumes? Ulli Horlacher
2019-07-05 19:47 ` Ulli Horlacher
2019-07-05 19:51   ` Hugo Mills
2019-07-05 19:56     ` Ulli Horlacher
2019-07-05 20:02       ` Hugo Mills [this message]

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=20190705200216.GR32479@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --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.