Any substance to this?
 

In the LQ blog here, the author states:

Is there currently any merit in that advice?

SuSE says go on btrfs in the production enterprise. What are everyone's observations here with btrfs on Slackware?

I had issues using btrfs as my root fs in Slackware 14 64 bit. I don't remember the exact issue, other than the system would not boot.

That was on top of lvm.

I have btrfs for /home under LVM. I haven't had a segfault (yet).

I agree that there may only be limited uses for btrfs on a lvm. That may not be very well tested. Btrfs has generally has enough features that one doesn't need to use it on top of lvm.

I personally would not use it that way but as noted, others seem to have done it.

Only the very latest kernel on some distros are stable to some degree. Btrfs is still not considered stable.

That makes no sense whatsoever.

My laptop had some issues with BtrFS during install, so I reverted it back to EXT4.

Where you using lilo as your boot manager because that combination (btrfs root and lilo) is flaky (search the forum and your will find numerous reports and some suggestions as to why).

The only problems I've encountered so far were immediately following install. I posted a plea for help in the Slackware installation forum but there was no response. That will be the last time I post there. Even I never look there, except when I'm alerted by zero reply notifications.

Anyway, the problem I had was fixed when I beer goggled a bit on the btrfs wiki and a couple of other places.

Setting fs_passno to "0" for all mount points that are btrfs in /etc/fstab and then copying /bin/true over /sbin/fsck.btrfs fixed the problem - btrfs doesn't need that, and the error I got was that / was already mounted.

So far it appears to rock.

Whether it is still experimental or ready for prime time appears to be heavily distro centric. i.e., SuSE says it is supported for production use at this time.

So no one's really mentioned any known gotcha's so far, other than Richard Cranium and ReaperX7, and I suspect their issues were the same as mine.

@rurario, From what I've been reading I get just the opposite - that some versions of Grub have issues, and to use ExtLinux I think as a workaround. I'm tired though and I might be the one who has that part backwards ;)

Any suggetions for taking it on a shakedown cruise?

I don't recall saying thet Extlinux wouldn't work with a btrfs root or boot partition. ;)

Actually we recently discussed this another thread:

So if you want to use btrfs your options appear to be:

• Have a small ext (2, 3 or 4) /boot partition and use btrfs for the rest
• Use Extlinux (part of the Syslinux, included with Slackware)
• Get Grub2 from SlackBuilds.org

There is a page on the Syslinux Wiki called Development/LVM support, that would seem to suggest that although Syslinux/Extlinux supports btrfs, it may not support LVM. Though I cannot be certain as that page has not been updated since 2011 and I have done no further investigation. Anyway that might be why the author advises against that combination.

If it is true that Extlinux will not work with LVM, then you either need a separate /boot or will have to look at Grub2. Personally I would keep things simple and just use a separate /boot formatted to ext{2,3,4}, that way you can be certain that you use either of the two bootloaders that ship with Slackware. Otherwise you might find you have to compile Grub2 and all its dependencies and mess around with its complex configuration options.

P.S. The fact that you even have to think about issues like this gives me the feeling that btrfs isn't quite there yet.

I don't think it's any different than the issues you get with putting your rootfs on LUKS. Encrypted root requires a separate /boot so issues like this aren't unusual. IMO having a separate /boot is probably a wise move no matter what filesystems/layout/bootloader you use.

Fair point

+1 to this! :D

I didn't want to touch Grub, and although it might be interesting to try extlinux, Lilo is what I've been using (and find more friendly than the others, actually) for twenty years. It wasn't always the case that we used a /boot. I think the popularity - indeed the prerequisite - of doing so w/an 8MByte /boot partition starting appearing around the time of the Maxtor 540MByte HDDs. The cylinder limit mandated this methodology and regardless of whether it was required or not most people just adopted that method as a matter of course.

So I agree that one might as well just go w/a /boot as part of a 'best practice', even though it's not strictly necessary in most cases anymore. Certainly, for xfs on / it is necessary, so the only real difference for me was in choosing btrfs for mounting / and the others, using Ext2/3/4 for /boot.

The scenario of the original problem I had is documented HERE. An image is there to depict what that non-boot scenario looked like.

I've posted that solution above in this thread, as I did in that earlier thread. Since the only real problems I've seen in the posts above (btrfs w/or without LVM) are seemingly related to the limitations of extlinux w/LVM, complexities w/Grub, attempting to use Lilo w/no /boot; and two other people above who *might* have experienced the same issue as me (btrfs doesn't need, nor should undergo a file system check on boot), some mention of this in future editions of http://slackware.osuosl.org/slackwar...README_LVM.TXT might be in order for both btrfs and xfs.

I'm still not seeing any recent nightmarish stories from anyone on the operation of btrfs on Slackware, and tend to not just agree with Gazl and ruario that Lilo + /boot is a good practice, but moreso should in most cases be considered the "Standard" practice :)

I don't care much for grub, and tend to look at other solutions as tomorrow's viable alternatives for UEFI. I just like Lilo I guess, and I also prefer fdisk (or gdisk) over that of cfdisk or cgdisk and the others too.

So at this point, I guess it would be nice to know if there is a better, or more preferred way of making those final adjustments, as opposed to the changes I made to /etc/fstab and clobbering fsck.btrfs in the chrooted environment prior to the reboot which fires up the the Slackware installation for the first time.

I'd like to add that while answering another question in the forum, I found this option that is part of mkinitrd:
I can definitely state that I had not added that option to my mkinitrd invocation, so that was the source of my problems with btrfs and my root logical volume. On my laptop, I've got my /var logical volume formatted with btrfs and have not seen any issues so far.

I've been using btrfs on my root filesystem (with an ext2 boot) with no problems. Setup with slackware 14, and upgraded to current. Works fine here. Also, using lilo.