archive mirror
 help / color / mirror / Atom feed
From: C Anthony Risinger <>
To: "" <>
Subject: Re: default subvolume abilities/restrictions
Date: Wed, 19 May 2010 09:01:47 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <29213501.290601274270192630.JavaMail.defaultUser@defaultHost>

On Wed, May 19, 2010 at 6:56 AM, <> wrote:
> 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?

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?

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

  reply	other threads:[~2010-05-19 14:01 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 [this message]
2010-05-19 17:58   ` Goffredo Baroncelli
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).