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 -- 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
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-- 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
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 -- 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
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
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-- 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
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 -- 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
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 -- 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
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>-- 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
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 -- 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
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 withIIRC 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 -- 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
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 -- 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
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 -- 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
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 > . >-- 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
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 :DThat''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 -- 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