archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <>
To: C Anthony Risinger <>
Subject: Re: default subvolume abilities/restrictions
Date: Wed, 19 May 2010 19:58:04 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wednesday, May 19, 2010, C Anthony Risinger wrote:
> On Wed, May 19, 2010 at 6:56 AM, <> 
> > Hi Anthony,
> >
> > I think that for you may be interested to read this thread
> >
> >
> >
> > and to read a my blog about this argument
> >
> >
> >
> > Regards
> > Goffredo
> thanks for the pointers, however the thread doesn't really offer a
> solution or an indication of whether this will/can be possible :-(,
> and your blog basically comes to the same conclusion that i already
> agree with; the system should be installed into a subvolume from day
> 1.  i could be mistaken here, but in my experience, you cannot remove
> a subvolume that has another subvolume within it.  thus, setting a new
> default subvolume doesn't actually change the heirarchy of subvolumes,
> and since the original default subvol (.) contains all other
> subvolumes, it still cannot be removed, as it's the ultimate parent
> subvolume (even though it's not necessarily the default anymore).  is
> this correct?

On the basis of my experiences I agree with you. I think that it was not a 
good design to link the subvolumes to directory entries. I prefer that the 
subvolumes live in a different namespace, and it were mounted when required.

> i need a way, programmatically and safely, to "move" the users
> installation from the original subvolume into an isolated subvolume
> called __active (what you called "rootfs" in you thread/blog), or to
> generate a new, empty default/root subvolume and place the current
> default subvol (.) _into_ it...  how can this be done?  until i figure
> this out i have to tell the user to manually remove the stagnant files
> from the dot (.) subvolume (usr/etc/lib...), since i don't think my
> users would appreciate me issuing an "rm -rf" against their system.
> any other ideas/input?

I am not sure to have understood well. But a possible solution may be to 
- snapshot the default subvolume to a rootfs.
- boot in the rootfs subvolume
- mount the default subvol (mount -o subvol=default /dev/sdX /mnt/default)
- remove (carefully) the file under the default subvolume except the  
subvolume(s) (something like rm --one-file-system /mnt/default/).

> C Anthony
> ps. a recursive snapshotting tool could be useful too (if / and /home
> were both subvols, the tool would create both when / was snapped,
> instead of /home being an empty folder in the snapshot).

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to
> More majordomo info at

gpg key@ Goffredo Baroncelli (ghigo) <>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

  reply	other threads:[~2010-05-19 17:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 11:56 R: default subvolume abilities/restrictions kreijack
2010-05-19 14:01 ` C Anthony Risinger
2010-05-19 17:58   ` Goffredo Baroncelli [this message]
2010-06-12  5:24   ` C Anthony Risinger
2010-06-12 23:06     ` C Anthony Risinger
2010-06-13  0:22       ` David Brown
2010-06-13  1:06         ` C Anthony Risinger
2010-06-13 17:47           ` C Anthony Risinger
2010-06-18 21:01             ` C Anthony Risinger
2010-06-29 13:20               ` Hubert Kario
2010-06-29 15:23                 ` Goffredo Baroncelli
  -- strict thread matches above, loose matches on Subject: below --
2010-05-19  6:50 C Anthony Risinger
2010-05-19 14:20 ` Chris Ball
2010-05-19 14:55   ` C Anthony Risinger

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

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