Moving top level to a subvolume

Moving top level to a subvolume

[Matthew Hawn]

I just converted my root filesystem to btrfs with btrfs-convert.  However, since I am running Ubuntu, I would like to have the same subvolume structure as a default install,. How do I move the top-level subvolume (where all my files currently are) to another subvolume?

Matt

Re: Moving top level to a subvolume

[Arne Jansen]

On 06/08/2012 09:24 PM, Matthew Hawn wrote:
> I just converted my root filesystem to btrfs with btrfs-convert.  However, since I am running Ubuntu, I would like to have the same subvolume structure as a default install,. How do I move the top-level subvolume (where all my files currently are) to another subvolume?
> 

Just snapshot the root subvol and continue working in the snapshot.


> Matt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving top level to a subvolume

[C Anthony Risinger]

On Fri, Jun 8, 2012 at 2:40 PM, Arne Jansen <sensille@gmx.net> wrote:
> On 06/08/2012 09:24 PM, Matthew Hawn wrote:
>> I just converted my root filesystem to btrfs with btrfs-convert.  However, since I am running Ubuntu, I would like to have the same subvolume structure as a default install,. How do I move the top-level subvolume (where all my files currently are) to another subvolume?
>
> Just snapshot the root subvol and continue working in the snapshot.

... yeah but that solution totally sucks when you:

a) have a lot of data
b) need to do this via script
c) ???

... because in a), data will *copied* the slow way, and in b) you
leave a bunch of junk laying around in the old root that will rot
unless you `rm -rf` it ... and idk about you, but issuing what is very
near to that command on someone else's machine -- via script -- makes
me REALLY uneasy ;-)

i have asked this exact question at least 4 times specifically, and
referenced it probably 8-10, in the last 3 years or more.  i needed it
then.  i still need it now.  but since i never got an answer up/down
or around, i gave up and told people to `rm -rf`themselves ...

http://markmail.org/message/7hj5ioqrztkeerqv

... that's from May of 2010, but i don't think it's the first.

so, would it possible to implement this, or could someone kindly (and
briefly!) explain why it cannot be done?

1. people install stuff to the top-level
2. top-level is unmanageable
3. ^^^^ problem

in my case i wrote an initramfs hook that implemented rollback
functionality, but there was not way for me to cleanly -- and safely
-- "rotate" the user's setup to one that DOES NOT have user items in
the top-level volume.

-- 

C Anthony

Re: Moving top level to a subvolume

[Arne Jansen]

On 13.06.2012 09:04, C Anthony Risinger wrote:
> On Fri, Jun 8, 2012 at 2:40 PM, Arne Jansen <sensille@gmx.net> wrote:
>> On 06/08/2012 09:24 PM, Matthew Hawn wrote:
>>> I just converted my root filesystem to btrfs with btrfs-convert.  However, since I am running Ubuntu, I would like to have the same subvolume structure as a default install,. How do I move the top-level subvolume (where all my files currently are) to another subvolume?
>>
>> Just snapshot the root subvol and continue working in the snapshot.
> 
> ... yeah but that solution totally sucks when you:
> 
> a) have a lot of data
> b) need to do this via script
> c) ???
> 
> ... because in a), data will *copied* the slow way, and in b) you
> leave a bunch of junk laying around in the old root that will rot
> unless you `rm -rf` it ... and idk about you, but issuing what is very
> near to that command on someone else's machine -- via script -- makes
> me REALLY uneasy ;-)

well, don't put data in the top level in the first place. Yes, you have
to remove the content of the subvol / by rm -rf, but I don't really see
the problem with it.
What I don't understand is why you think data will be copied.

> 
> i have asked this exact question at least 4 times specifically, and
> referenced it probably 8-10, in the last 3 years or more.  i needed it
> then.  i still need it now.  but since i never got an answer up/down
> or around, i gave up and told people to `rm -rf`themselves ...
> 
> http://markmail.org/message/7hj5ioqrztkeerqv
> 
> ... that's from May of 2010, but i don't think it's the first.
> 
> so, would it possible to implement this, or could someone kindly (and
> briefly!) explain why it cannot be done?

The default subvol ('/') has the special number 5 and is expected to
always be around. All other subvols get numbers starting with 256.
Creating a new 5 and internally renumbering the old 5 isn't easy, because
each tree block has an owner recorded in it. Also, all backreferences
have the root number in them. If you have to touch each tree block, you
can as well choose the snapshot/rm -rf approach.

> 
> 1. people install stuff to the top-level
> 2. top-level is unmanageable
> 3. ^^^^ problem
> 
> in my case i wrote an initramfs hook that implemented rollback
> functionality, but there was not way for me to cleanly -- and safely
> -- "rotate" the user's setup to one that DOES NOT have user items in
> the top-level volume.

Can't instead add code to the installer that warns a user if he wants
to install into the default subvol?
Or you could hack mkfs.btrfs to always create an additional subvol.
Even making / readonly except for creating mountpoint could be possible.
Just some random ideas...

-Arne

> 

Re: Moving top level to a subvolume

[C Anthony Risinger]

On Wed, Jun 13, 2012 at 2:21 AM, Arne Jansen <sensille@gmx.net> wrote:
> On 13.06.2012 09:04, C Anthony Risinger wrote:
>>
>> a) have a lot of data
>> b) need to do this via script
>> c) ???
>>
>> ... because in a), data will *copied* the slow way, and in b) you
>> leave a bunch of junk laying around in the old root that will rot
>> unless you `rm -rf` it ... [...]
>
> What I don't understand is why you think data will be copied.

at one point i tried to create a new subvol and `mv` files there, and
it took quite some time to complete
(cross-link-device-what-have-you?), but maybe things changed ... will
try it out.

>> [...]
>>
>> so, would it possible to implement this, or could someone kindly (and
>> briefly!) explain why it cannot be done?
>
> The default subvol ('/') has the special number 5 and is expected to
> always be around. All other subvols get numbers starting with 256.
> Creating a new 5 and internally renumbering the old 5 isn't easy, because
> each tree block has an owner recorded in it. Also, all backreferences
> have the root number in them. If you have to touch each tree block, you
> can as well choose the snapshot/rm -rf approach.

ok this makes sense thanks, the last sentence especially ... top-level
volume is different.  it's identical to other subvols in 99% of ways
save one-gotcha-little-1%.  couldn't we shield ourselves a little
better?

>> 1. people install stuff to the top-level
>> 2. top-level is unmanageable
>> 3. ^^^^ problem
>> [...]
>
> Can't instead add code to the installer that warns a user if he wants
> to install into the default subvol?


> Just some random ideas...

i would like to see #5 cut off from natural access: accessible by an
_explicit_ manual mount only, cannot be made default, and cannot be
removed. maybe btrfs manages a proxy/facade subvol, say, #10, settable
by `--flag-origin` or `{insert-here}` option -- a symlink to subvol?
if, at absolutely any time or whatever reason, #10 pointer should not
exist, immediately snapshot #5 and update.

#5 -> #10 -> #256+ ?

... this might allow the root to be "replaced".  default is set to #10
proxy volume when FS is initialized.

> [...]
> Or you could hack mkfs.btrfs to always create an additional subvol.
> Even making / readonly except for creating mountpoint could be possible.

^^^^^ yeah, this sounds like exactly what i'm thinking, differing
mainly on who does the work... i just want a guaranteed way of
replacing the "logical root", at #10.  the "physical root" at #5 it's
more-or-less indestructible and off limits, and never available except
as a template.

... i am new to postgresql, but their template0/template1 feels
related to solving problems like this.

-- 

C Anthony

Re: Moving top level to a subvolume

[Fajar A. Nugraha]

On Wed, Jun 13, 2012 at 4:44 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
> On Wed, Jun 13, 2012 at 2:21 AM, Arne Jansen <sensille@gmx.net> wrote:
>> On 13.06.2012 09:04, C Anthony Risinger wrote:

>>> ... because in a), data will *copied* the slow way

>> What I don't understand is why you think data will be copied.

> at one point i tried to create a new subvol and `mv` files there, and
> it took quite some time to complete
> (cross-link-device-what-have-you?), but maybe things changed ... will
> try it out.

IIRC it hasn't. Not in upstream anyway. Some distros (e.g. opensuse)
carry their own patch which allows cross-subvolume links (cp --reflink
...).

But it shouldn't matter anyway, since you can SNAPSHOT the old subvol
(even root subvol), instead of creating a new subvol. Which means
nothing needs to be copied.

You'd still have to do "rm" manually though.

-- 
Fajar

Re: Moving top level to a subvolume

[Goffredo Baroncelli]

On 06/13/2012 09:21 AM, Arne Jansen wrote:
> On 13.06.2012 09:04, C Anthony Risinger wrote:
>> On Fri, Jun 8, 2012 at 2:40 PM, Arne Jansen <sensille@gmx.net> wrote:
>>> On 06/08/2012 09:24 PM, Matthew Hawn wrote:
>>>> I just converted my root filesystem to btrfs with btrfs-convert.  However, since I am running Ubuntu, I would like to have the same subvolume structure as a default install,. How do I move the top-level subvolume (where all my files currently are) to another subvolume?
>>>
>>> Just snapshot the root subvol and continue working in the snapshot.
>>
>> ... yeah but that solution totally sucks when you:
>>
>> a) have a lot of data
>> b) need to do this via script
>> c) ???
>>
>> ... because in a), data will *copied* the slow way, and in b) you
>> leave a bunch of junk laying around in the old root that will rot
>> unless you `rm -rf` it ... and idk about you, but issuing what is very
>> near to that command on someone else's machine -- via script -- makes
>> me REALLY uneasy ;-)
> 
> well, don't put data in the top level in the first place. Yes, you have
> to remove the content of the subvol / by rm -rf, but I don't really see
> the problem with it.

It is slow. You have to change a lot of metadata (each shared metadata
block have to be unshared, and then one copy will be deleted ).

> What I don't understand is why you think data will be copied.
> 
>>
>> i have asked this exact question at least 4 times specifically, and
>> referenced it probably 8-10, in the last 3 years or more.  i needed it
>> then.  i still need it now.  but since i never got an answer up/down
>> or around, i gave up and told people to `rm -rf`themselves ...
>>
>> http://markmail.org/message/7hj5ioqrztkeerqv
>>
>> ... that's from May of 2010, but i don't think it's the first.
>>
>> so, would it possible to implement this, or could someone kindly (and
>> briefly!) explain why it cannot be done?
> 
> The default subvol ('/') has the special number 5 and is expected to
> always be around. All other subvols get numbers starting with 256.
> Creating a new 5 and internally renumbering the old 5 isn't easy, because
> each tree block has an owner recorded in it. Also, all backreferences
> have the root number in them. If you have to touch each tree block, you
> can as well choose the snapshot/rm -rf approach.

I don't know very well the internal of btrfs. Do you think that It is
possible to move/swap the root subvolume ?

> 
>>
[...]

> Or you could hack mkfs.btrfs to always create an additional subvol.

Which can be the default one: so nobody should complain. I



> Even making / readonly except for creating mountpoint could be possible.
> Just some random ideas...
> 
> -Arne
> 
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 

Re: Moving top level to a subvolume

[Duncan]

Matthew Hawn posted on Fri, 08 Jun 2012 12:24:26 -0700 as excerpted:

> I just converted my root filesystem to btrfs with btrfs-convert. 
> However,
> since I am running Ubuntu, I would like to have the same subvolume
> structure as a default install,. How do I move the top-level subvolume
> (where all my files currently are) to another subvolume?

(Replied to list and to you, in case you're not subscribed.)

Arne answered your question, but just let me add a caution.

We get a lot of folks on this list who somehow miss the kernel warning, 
and the wiki warning, and the general community knowledge, that btrfs is 
still marked experimental and is still under heavy development.  If 
something goes wrong, as it often has for these folks when they post 
here...

So just be aware of that and be sure that if you're going to run it, you 
keep backups on something other than btrfs just in case, and that you 
keep them relatively current (depending on how much data from your btrfs 
systems you're willing to lose if it dies).

Also, it's worthwhile to keep up with this list to see current 
developments and bugs, to run a current kernel, generally meaning latest 
Linus release either stable or rc, and if you've not read up on the wiki, 
read up on btrfs there, too.

https://btrfs.wiki.kernel.org/

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Moving top level to a subvolume

[Randy Barlow]

On Tuesday, June 12, 2012 01:53:23 AM Duncan wrote:
> We get a lot of folks on this list who somehow miss the kernel warning, 
> and the wiki warning, and the general community knowledge, that btrfs is 
> still marked experimental and is still under heavy development.  If 
> something goes wrong, as it often has for these folks when they post 
> here...

I personally run Gentoo, but I've been told by some coworkers that the Ubuntu 
installer offers btrfs as an option to the users without marking it as 
experimental, unstable, or under development. I wonder if that is why we see 
so many people surprised when they lose their filesystems. Can anyone verify 
whether that is true of Ubuntu, or of any other Linux distributions?

-- 
R

Re: Moving top level to a subvolume

[Michael]

The Ubuntu wiki does not(in a straight-forward way) say BTRFS is
experimental and unstable. It looks like they copied and pasted from
the BTRFS official Wiki.
Link:  https://help.ubuntu.com/community/btrfs

I do not have an account on the BTRFS wiki, but I believe changing the
first paragraphs to something like what I included at the bottom. The
big change is that we need to specifically and in big bold letters say
that BTRFS is experimental and unstable as well as outline that BTRFS
shouldn't be used on data where loss would cause headaches.
I don't think that as is we draw enough attention to these facts. We
are assuming that by saying(on the Wiki) "Btrfs is under heavy
development" people will realize that it is experimental and unstable.
Right after that we say that "every effort is being made to keep the
filesystem stable and fast" which reads more like, "we are making
every effort to KEEP it stable and fast". This ambiguity would lead
users to believe that BTRFS is fast and stable(instead of that "we are
attempting to have it be fast and stable")
----
Btrfs is under heavy development, but while every effort is being made
to keep the filesystem stable and fast, it is still marked as
[bold][bold]experimental and unstable[/bold][/bold]. Btrfs should not
yet be used on data where loss would cause headaches. Because of the
speed of development, you should run the latest kernel you can (either
the latest release kernel from kernel.org, or the latest -rc kernel.
Please email the Btrfs mailing list if you have any problems or
questions while using Btrfs.
----

On Tue, Jun 12, 2012 at 9:52 AM, Randy Barlow
<randy@electronsweatshop.com> wrote:
>
> On Tuesday, June 12, 2012 01:53:23 AM Duncan wrote:
> > We get a lot of folks on this list who somehow miss the kernel warning,
> > and the wiki warning, and the general community knowledge, that btrfs is
> > still marked experimental and is still under heavy development.  If
> > something goes wrong, as it often has for these folks when they post
> > here...
>
> I personally run Gentoo, but I've been told by some coworkers that the Ubuntu
> installer offers btrfs as an option to the users without marking it as
> experimental, unstable, or under development. I wonder if that is why we see
> so many people surprised when they lose their filesystems. Can anyone verify
> whether that is true of Ubuntu, or of any other Linux distributions?
>
> --
> R
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving top level to a subvolume

[Fajar A. Nugraha]

On Tue, Jun 12, 2012 at 9:52 PM, Randy Barlow
<randy@electronsweatshop.com> wrote:
> I personally run Gentoo, but I've been told by some coworkers that the Ubuntu
> installer offers btrfs as an option to the users without marking it as
> experimental, unstable, or under development. I wonder if that is why we see
> so many people surprised when they lose their filesystems. Can anyone verify
> whether that is true of Ubuntu, or of any other Linux distributions?

Oracle linux (when used with UEK2) officially supports btrfs. Opensuse
also supports btrfs, and use its functionality for snapper.

I haven't found any updated (i.e. released post 12.04) official
support status statement from Ubuntu, but they do offer btrfs as
installation option.

As for "lose their filesystems", are there recent ones that uses one
of the three distros above, and is purely btrfs "fault"? The ones I
can remember (from the post to this list) were broken on earlier
kernels, or caused by bad disks.

-- 
Fajar

Re: Moving top level to a subvolume

[Duncan]

Fajar A. Nugraha posted on Wed, 13 Jun 2012 08:49:47 +0700 as excerpted:

> As for "lose their filesystems", are there recent ones that uses one of
> the three distros above, and is purely btrfs "fault"? The ones I can
> remember (from the post to this list) were broken on earlier kernels, or
> caused by bad disks.

I tried btrfs during the 3.4 cycle for a bit, and didn't lose the whole 
filesystem, but definitely found it not upto my usual standard of 
robustness, my previous and back to now filesystem, Chris's former 
project, reiserfs.

My system's old and has a bit of a problem with overheating in the 
Phoenix summer, so has been suffering SATA resets (not the disk, the sata 
chipset most likely, and/or issues with the graphics overheating since 
I'm using an AMD 8xxx chipset with AGPGART split between IOMMU for 
storage I/O and graphics) and full system freezes.

Not only did I have way more stuff disappearing or being zeroed out than 
on reiserfs (in default data=ordered mode), but in one case I had a 
segment disappear out of the middle of a file, and in another, I had 
firefox's crash-resume-file /content/ show up as what SHOULD have been an 
entirely unrelated configuration file.

Naturally I had backups to restore from, and if it wasn't for the 
freezes, it would have likely been fine, but it's exactly this sort of 
corner-case that filesystems need to be able to deal with, and what 
bothered me wasn't disappearing or zeroed out last few seconds of work 
with well documented explanations, but having random segments of files 
that I hadn't changed (whether the app was rewriting them with the same 
data's another question) in some time disappear, and having one file's 
content show up with an entirely unrelated name.  I thought that's the 
sort of thing btrfs checksums were supposed to detect and effectively 
zero out, but...

I decided that's /too/ experimental for me ATM, especially with not-quite-
stable hardware (it's worth noting that I survived bad memory and the 
related crashes on reiserfs, without /that/ sort of damage, at least not 
since data=ordered mode!), so am back on reiserfs for now, anyway.  I'll 
likely try again next year sometime...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Moving top level to a subvolume

[Fajar A. Nugraha]

On Wed, Jun 13, 2012 at 2:23 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Fajar A. Nugraha posted on Wed, 13 Jun 2012 08:49:47 +0700 as excerpted:
>
>> As for "lose their filesystems", are there recent ones that uses one of
>> the three distros above, and is purely btrfs "fault"? The ones I can
>> remember (from the post to this list) were broken on earlier kernels, or
>> caused by bad disks.

> My system's old and has a bit of a problem with overheating in the
> Phoenix summer, so has been suffering SATA resets

> it's exactly this sort of
> corner-case that filesystems need to be able to deal with

IIRC XFS had corruption problems when used on top of LVM (or other
block device that doesn't support barriers correctly), while using
ext2/3/4 on the same block device will be "fine". Yet XFS doesn't have
the mark of "unstable, highly experimental, do not use". People simply
use the right (for them) fs for the right job.

My point is yes, btrfs is new. And it's being developed at much faster
rate than any other more-mature fs out there. And there are known
cases of data loss on certain configuration of corner cases/"buggy"
hardware and/or old version of kernel. But when used in the correct
environment, btrfs can be a good choice, even for critical data.

Of course IF the data were REALLY critical, and I REALLY need btrfs'
features, and it were on an enterprise environment, I would've bought
support from oracle linux (or SLES 12, when it's out, or whatever
enterprise distro supporting btrfs which sells support contract) so I
can have someone to turn to in case of problems, and (in some cases)
transfer the risk/blame :D

-- 
Fajar

Re: Moving top level to a subvolume

[Duncan]

Fajar A. Nugraha posted on Wed, 13 Jun 2012 16:08:40 +0700 as excerpted:

>> My system's old and has a bit of a problem with overheating in the
>> Phoenix summer, so has been suffering SATA resets
> 
>> it's exactly this sort of corner-case that filesystems need to be able
>> to deal with
> 
> IIRC XFS had corruption problems when used on top of LVM (or other block
> device that doesn't support barriers correctly), while using ext2/3/4 on
> the same block device will be "fine". Yet XFS doesn't have the mark of
> "unstable, highly experimental, do not use". People simply use the right
> (for them) fs for the right job.

It /does/ have a reputation of "don't use for a normal home system or 
other location without a suitably dependable UPS on fully stable 
hardware", however.  (From what I've read however, much like reiserfs has 
been for me here after data=ordered, xfs is vastly improved now, and said 
reputation likely no longer applies.)

If btrfs is to replace ext3/4, then that sort of reputation isn't what 
its devs will be shooting for.  We have at least the two filesystems 
(reiserfs and xfs) with serious reputation problems from their earlier 
life, and my big concern is that if enough people fail to consider btrfs' 
current development state and end up with data loss as a result, btrfs 
will end up with a very similar reputation, which will similarly live 
many years longer than the reality that created it.  But the other two 
weren't shooting for the ext* mantle, and btrfs is.  If its reputation is 
damaged to that extent and it becomes the assumed Linux default as ext3/4 
is now, that will be the Linux reputation.

> My point is yes, btrfs is new. And it's being developed at much faster
> rate than any other more-mature fs out there. And there are known cases
> of data loss on certain configuration of corner cases/"buggy" hardware
> and/or old version of kernel. But when used in the correct environment,
> btrfs can be a good choice, even for critical data.

Of course, critical data is backed up, or by definition you don't REALLY 
consider it so critical after all.  (There was a time when drives were 
small enough and expensive enough, as were the alternatives, that wasn't 
the case.  That time is long gone, for first and second world usage, 
anyway.  Even a home user with a single drive can split it into multiple 
partitions, with backup data on separate partitions, at least, with the 
real critical data on a thumb-drive too.)

But while people can and do unfortunately go without backups and are 
often lucky, doing so on btrfs at this stage in its development is 
"doubly insane", to channel Linus (actually being nice that day =:^) 
describing a recent commit, in his revert.

But there's obviously "doubly insane" people out there! =:^\

> Of course IF the data were REALLY critical, and I REALLY need btrfs'
> features, and it were on an enterprise environment, I would've bought
> support from oracle linux (or SLES 12, when it's out, or whatever
> enterprise distro supporting btrfs which sells support contract) so I
> can have someone to turn to in case of problems, and (in some cases)
> transfer the risk/blame :D

That's a good point.  Of course, as many people find out, such "support" 
often /does/ really come down to "someone else to blame".  Yes, they'll 
help with recovery if it comes to it, but if your $100K+ an hour business 
is down in the mean time... and you didn't have those backups and at 
/least/ "cold" failover... they'll be finding someone to blame as well!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman