Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back > Blogs > Lumak's Guide to Random Things
User Name


OK I don't really have a good title yet but I figure I can post works in progress and other tips I've come across or other interesting things.
Rate this Entry

Playing with BtrFs and thinking out loud.

Posted 04-30-2011 at 05:53 AM by lumak
Updated 04-30-2011 at 07:12 AM by lumak

Warning: I'm mainly jotting things down so it may be a bit out of order.

During the install of Slackware 13.37, I figured I would give BtrFs a try and see how it goes. I quickly found out that BtrFs is NOT designed for small partitions. Where it used to be common practice to have something like the following, the same is not true for BtrFs:

Primary Partition
/boot  - 100M - ext3

Luks encrypted LVM
/      - 1G   - btrfs
/var   - 500M - btrfs
/usr   - 37G  - btrfs
/home  - 7.5G - ext4
swap   - 3G   - This was an afterthought.  Even with 5gigs of ram, you still need swap.  I had space left outside of the Luks/LVM but I wanted encrypted swap without having to manage another LUKS partition.

Large Share of insensitive data on Logical Extended Partition
/home/share - 625G - reiserfs - I haven't got around to playing the data movement game to change.

/tmp - tmpfs - I've never cared to save this data between rebooting.
As I found out, the structure of btrfs does not allow you to have the full space available of the partition so 1G is more like 500M (600M-ish if you re-balance) and 500M is 250M. The goal of BtrFs seems to be a lot like LVM where you can expand over multiple drives and expand as your needs expand.

That's fine, I now have the chance to play around with LVM sizing and BtrFs subvolumes.

BTW I KNOW (now) - BtrFs in it self doesn't match well with LVM. Please spare me the response about how I'm not supposed to put a BtrFs on an LVM logical volume.

Anyway, it seems my solution now (for experimentation) is to consolidate the LVM partitions root, var, and usr -- increase the BtrFs over that partition -- create sub volumes -- move some file names around to the subvolumes -- edit fstab -- rebalance and defrag for good measure.

At least... I think I can do all that. To my understanding LVM is flexible on how it manages its data as it does not have to be contiguous. And because of that, it should be nothing to increase the BtrFS size after consolidating the three partitions. I'm not playing with important data here so I can afford to screw up. I don't think I'll mess up that badly and destroy the data on /home and /home/share


Anyway... All this got me thinking, what are even the use cases of subvolumes? if you mount the root subvolume, you automatically have access to all the data in the subvolumes. And it's not like remounting a subvolume is anything significant, you can already do this with bind.

However, while typing the above I thought of a very interesting scenario that could be useful to software developers. For example:

We are still transitioning from 32bit to 64bit. So it's often the case that we may need to dual boot, develop in one or the other without reboot, use multilib, etc.

BtrFs actually lets you easily do the above with subvolumes while reducing the need to duplicate data for the multilib.

root (default subvolume)
.. /
.. usr
.. usr/bin
.. usr/lib
.. lib
.. anything else you want to share
.. /
.. Anything you think you might need to make separate snapshots of.

With this setup, you can now share the full partition between both OSes and boot into either one. Data stays separate and there is no need to specify how large each subvolume is. They all report the same size (a minor inconvenience to bar-graphs of diskusage... just use one subvolume). This alone is a good reason for using btrfs.

Now you can mount lib and usr/bin of the 32bit os into your 64bit os! Both oses are independent and you get a multilib compatibility layer (other than the compilers). Since both slackware64 and slackware32 are identical, there is no need to duplicate non architecture sensitive data like configurations or documentation.

However. There is a 'Gotcha' with using /lib from the 32bit OS in the 64bit OS. Slackware uses the FSF recommendation of /lib and /lib64 under multilib. But others use /lib and /lib32. This causes problems with a direct share of the 32bit /lib on the 64bit OS because there are still files installed in /lib from the 64bit os. The dhcpcd, firmware, modules, and udev directories for example. This would involve doing some playing around with the subvolumes on both OSes to avoid collisions. Also, there are files in the main alienbob multilib packages that get installed to /lib... glibc-solibs, gcc, glibc. However, these are probably binary compatible with the same files that would get installed under a normal 32bit install. I haven't quite worked out how to get around this yet. Maybe there is a way to mount the 32bit /lib in the 64bit os while keeping changed data on the 64bit copy of /lib?

I suppose you could be really messy have 32bit subvolumes as:
lib-dirs (with all directories, not just dhcpcd, firmware, modules, and udev)

The 32bit OS would symlink all the files in lib-bin to /lib and all directories in lib-dirs to /lib.
This would obviously take some setup after installing the 32bit os.

The 64bit OS would have to do something strange like mounting lib-bin as /lib. Maybe removing the colliding binaries from the glibc-solibs, gcc, and glibc multilib packages. And symlink the dhcpcd, firmware, modules, and udev folders.

I say Simlink (rather than a subvolume mount), because the root filesystem has to be complete with at least /bin /sbin and /lib directories. The subvolumes are automatically available when any one of the parent volumes are mounted. e.g. slackware32-13.37.

You 'should' be able to get away with a blind mount of the 32bit bin, usr/bin sbin/, usr/bin to "32" subfolders on the 64bit OS. (bin/32, usr/bin/32, etc.) This is sort of what Alien Bob's multilib "massconvert" script does with the 32bit packages.

Ok that theory of use needs some work. But the above mentioned solution (while messy) would work. If I can do some more reading and figuring out, it's something that you can't exactly do with LVM and ext234 formats. You would have to somehow mount the root filesystem for both OSes and do some bind mounts or other strange things in the initrd image. That would require some custom scripts in the initrd to handover control to the correct OS folder and further script manipulation in the OS to ensure it stays with it.

I know BtrFs shares a lot of the same concepts as ZFS, and you can probably do this same thing with ZFS or maybe there is a more elegant way of doing it. I'm not claiming to know what I'm doing. Just thinking.

Looks like I need to do more reading before I try mucking with stuff.

EDIT: there is 'btrfstune' which can be used for enabling filesystem seeding, however it does not appear to function on sub volumes. Only block devices. I suppose you could have two partitions. One for the 32bit seed volumes and another volume that contains the readwrite 32bit filesystem(s) and 64bit filesystems(s). Arguably, this is even more useful for software development. It allows you to always have a static snapshot of the original OS as intended by the developers and multiple rw subvolumes that can be independently booted. There may need to be some additional setup, but I think this could work out well. If only Slackware came with btrfstune... It's not compiled by a base run of the 'make' command in the source tree.
Posted in Uncategorized
Views 2704 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 01:20 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration