Recomendations for BTRFS

anthillsocial · 2013-12-10 12:15:25

Hi All,

I'm on the verge of installing a new system on a couple of computers using BTRFS and after allot of reading I just wanted to check that I've got things clear in my head and wanted some recommendations. My two proposed systems are:

1. A home server with hardware Raid with a UFEI motherboard.
- Pure BTRFS filesystem (mkfs.btrfs on /dev/sda)
- Subvolume: __active/boot
- Subvolume: __active/home
- Snapshots of each subvolume (boot/home) managed with snapper.

Q1: I know that no UEFI boot is possible with a pure BTRFS filesystem, so my question is how will my system boot? Will simply issuing grub-install on /dev/sda mean that the system will boot, but just not in UEFI mode? Or do I need to do something else to the setup?

2. A lenovo T410 laptop.
- Pure BTRFS filesystem (mkfs.btrfs on /dev/sda)
- Subvolume: __active/boot
- Subvolume: __active/home
- Snapshots of each subvolume (boot/home) managed with snapper.

Q2. Same question as above.

Q3. I also know that with this setup no swap is possible, meaning that hibernation is out of the question, in which case what is a recommended setup with a laptop that needs to be able to hibernate? Or I suppose I could just live with suspend to RAM rather than disk?

Q4. Are alternative subvolumes recommended? Or are there any pitfalls I should look out for?

[edit] removed non-relevant text from end

Last edited by anthillsocial (2013-12-10 12:24:40)

WorMzy · 2013-12-10 12:36:36

I think you're unnecessarilly restricting yourself by a wanting a full disk btrfs, particularly if you want to use UEFI or hibernation.. why do you want to restrict yourself in such a way?

One tip I can offer is to disable compression on your /boot subvolume. And disable COW on your /var/log directory.

aya · 2013-12-10 13:08:57

From what I know grub will not boot if you have no partitions. At least it was so a year ago or so. You will probably need syslinux as a boot loader. At least it was so for BIOS.
You can still have swap via a swap file mounted over a loop device. Not fast but possible. I did not try to hibernate into it though.

The easiest way to know for sure is to fire up KVM or Virtualbox and try out your setup.

anthillsocial · 2013-12-10 14:09:19

Thanks for the replys.

RE: Unnecessarily restricting
I'm drawn to keeping things really simple with a pure BTRFS system. I'm not exactly sure what i will lose out on apart from the hibernation?

RE: From what I know grub will not boot
According to this post, it seems it will:
https://bbs.archlinux.org/viewtopic.php?id=166591
Perhaps i should just give it a go.

WorMzy · 2013-12-10 14:59:23

I don't think you'll "lose out" on anything else, I just think it's a strange choice. Making a 512MB FAT32 ESP will let you use UEFI (assuming your motherboard has the option to boot in UEFI mode), and making a 4GB swap file would enable you to use hibernation. I just don't see how simplicity is an argument for using a full disk filesystem when the alternative isn't complex.

At the end of the day though, this is your system, and you can set it up how you like.

WonderWoofy · 2013-12-10 15:28:08

aya wrote:

From what I know grub will not boot if you have no partitions. At least it was so a year ago or so.

This is no longer the case. I have tested this, and it works great with grub. Syslinux on the other hand is actually an issue. Syslinux searches for the partitions marked with the boot flag and looks for the c32 files there (as well as the config). So if there is no partition to mark as active... I haven't figured out how to get around that.

Btrfs on a whole disk doesn't actually start until after the first superblock. I believe that this is 64 sectors into the disk. This surprisingly leaves plenty of space for the massively bloated grub. The grub-mkconfig scripts also properly handle the existence of /boot within a subvol. So on my system, the rootfs is called... rootfs, and is located directly off of subvolid=0 (ie. I have /rootfs/{bin,boot,dev,etc,home,...} off the root of the fs). So grub actually automagically indicates the kernel at /rootfs/boot/vmlinuz-linux and then initramfs at /rootfs/boot/initramfs-linux.img. It also correctly sets the rootflags=subvol=rootfs (though I am not sure if this is because I installed grub with this in my /proc/cmdline).

I see you are using the subvolume naming scheme that is recommended by the mkinitcpio-btrfs. I honestly think that this hooks is pretty worthless. If you have a general understanding of how your subvolumes are set up (where you keep your snapshots), then rolling back can be as simple as changing the kernel command line before boot. Rolling back non-root subvols is a bit more involved, but in my mind it still doens't justify a needlessly complex and unsupported initramfs hook.

I am with WorMzy on this though. There is no real advantage to a whole disk btrfs if you are not using it as just simple btrfs raid storage. It may seem cool (and indeed, it is cool), but losing the ability to partition your one drive is not worth this cool factor. If you machine supports UEFI, it would probably be a good idea to have a EFI System Partition and try to set things up using it. It can live alongside grub-bios without issue, and in fact I use UEFI, but I also have grub-bios set up just in case all shit goes awry.

Edit: What you lose out on, besides hibernation and UEFI, by having a whole disk btrfs is the ability to change your mind later. If you were just to make a single partition and put btrfs across that, at least you cound then resize the btrfs and partition and add an ESP later (or swap partition). Btrfs makes filesystem resizing unbelievably simple, and is something that I have used many times to add a temporary small partition for various things.

Last edited by WonderWoofy (2013-12-10 15:30:57)

anthillsocial · 2013-12-10 15:57:12

Thanks WoderWoofy/WorMzy

RE: mkinitcpio-btrfs.
Thanks for the heads up - I hadn't intended to use it, it was just a naming convection that had stuck in my various notes i'd been making.

RE: You lose out on the ability to change your mind later.
Of course. A very good reason to have at least one partition.

anthillsocial · 2013-12-11 14:53:58

Ok. I'm now trying to get my head around what my final system will look like. I've been ready many blog posts, tutorials and forum posts & there's a ton of conflicting information out there, so I want to be sure i get it right for my needs & I must admit I find it all quite confusing!

This is what I'm currently working through (lots taken from WonderWoofy suggestions on the forum;) - please do correct me if i'm incorrectly using terminology.

A. Partitions / Filesystem:
/dev/sda1 = 1GB EFI System Partition (ESP) Fat32
/dev/sda2 = Rest of disk as btrfs filesystem
/dev/sda3 = 4GB swap disk

B. Structure of /dev/sda2, the whole btrfs filesystem:
├── home (a btrfs subvolume)
├── pacpkg (a btrfs subvolume)
├── rootfs (a btrfs subvolume)
└── snaps (a directory)

Which is created with:
# mkdir /mnt/btrfs
# mount -o defaults,relatime,autodefrag /dev/sda2 /mnt/btrfs
# cd /mnt/btrfs
# btrfs subvolume create home
# btrfs subvolume create pacpkg
# btrfs subvolume create rootfs
# mkdir snaps

C. Then mount the rootfs subvolume and create the root structure:
# mkdir /mnt/root
# mount -o defaults,relatime,nodev,subvol=rootfs /dev/sda2 /mnt/root
# cd /mnt/root
# mkdir home
# mkdir -p var/cache/pacman/pkg

D. Then mount the subvolumes to the root structure:
# mount -o defaults,relatime,nodev,nosuid,subvol=home /dev/sda2 /mnt/root/home
# mount -o defaults,relatime,nodev,nosuid,subvol=pacpkg /dev/sda2 /mnt/root/var/cache/pacman/pkg

F. Now to bootstrap the system, create the fstab and chroot
# pacstrap /mnt/root base base-devel
# genfstab -U -p /mnt/root >> /mnt/root/etc/fstab
# arch-chroot /mnt/root /bin/bash

G. Then as I have UEFI attempt to install gummiboot on the system partition
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars # ignore if already mounted
# pacman -S gummiboot
# gummiboot install

Now all this seems to work as expected until I get to installing gummiboot which expects /boot to be a FAT ESP, in which case, in section C should I create a boot directory and mount the ESP partition to it? Will the boot partition then be included in snapshots?

Or am I misunderstanding how to implement the bootloader? Any suggestions for getting past this stage gratefully received.

[edit: minor correction to grammar / spelling]
[edit: Added question to end]

Last edited by anthillsocial (2013-12-11 17:10:39)

anthillsocial · 2013-12-13 11:52:50

Any thoughts on this?

I think I may have been thrown by WorMzy's comment "Making a 512MB FAT32 ESP will let you use UEFI".
As I thought that one of the issues is that you can't boot arch running off a BTRFS root in UEFI mode?

In which case, did WorMzy mean that:
Making a 512MB FAT32 ESP will give you the option to use UEFI in the future or if I decide to multi boot, rather than it allowing me to boot my BTRFS system with UEFI at this moment in time?

WorMzy · 2013-12-13 13:06:41

You need an ESP (EFI System Partition) to boot using UEFI. If you have one, you won't be forced to use UEFI, but without one, you'll be forced to use the traditional/legacy BIOS boot method.

I'd say that 1GB is a bit overkill, a 512MB partition is recommended, though you can have bigger/smaller if you really want.

Some recommended reading:
https://en.wikipedia.org/wiki/EFI_System_partition
https://wiki.archlinux.org/index.php/Un … _Interface

you can't boot arch running off a BTRFS root in UEFI mode?

Of course you can. That's exactly what I do.

anthillsocial · 2013-12-13 13:46:10

In that case, does the ESP need to be mounted to /boot on the BTRFS I created?
And doesn't that prevent a snapshot being made of the entire system?

RE: Some recommended reading:
https://en.wikipedia.org/wiki/EFI_System_partition
https://wiki.archlinux.org/index.php/Un … _Interface

I've been reading those pages allot;) Though there's obviously something I'm not quite getting...

anthillsocial · 2013-12-13 13:55:42

Or is that you use an efistub with an efistub-update.service so that /boot & the efistub remain synced?

[EDIT] Ahh I've just seen this post: https://bbs.archlinux.org/viewtopic.php … 3#p1324763
"I have started using /boot/efi to mount my ESP as I use btrfs" which indicates that i'm starting to understand things correctly... I'll give that a try...

Last edited by anthillsocial (2013-12-13 14:14:22)

WonderWoofy · 2013-12-13 16:02:35

Its up to you where you mount it. But you have to remember that if you put it in a nonstandard place, you have to have something that will copy the kernel and initarmfs to the ESP if you use gummiboot or syslinux. I think that both grub and rEFInd are able to read off the btrfs partition (I know rEFInd for sure, as I have that set up).

I started mounting at /boot/efi simply to have the kernel and initramfs snapshotted with the rest of the filesystem. It makes it easier to have the matching kernel and /usr/lib/modules in the event that I ever want to boot from one of said snapshots. But if that is not something you care about, then mounting the ESP at /boot is probably the easiest way to do things.

ANOKNUSA · 2013-12-13 16:39:44

anthillsocial wrote:

In that case, does the ESP need to be mounted to /boot on the BTRFS I created?
And doesn't that prevent a snapshot being made of the entire system?

This is just my thinking here, but for most home users a snapshot of the entire system seems a bit unnecessary, and really limits what you might do with the system. BTRFS snapshots are not recursive; if you want to make a single snapshot of the entire system, then the system must exist within a single root subvolume, and no other subvolumes may exist within that root subvolume. I'd like to think of BTRFS snapshots more as a version control system for the filesystem than a full system recovery tool: Make subvolumes for things that may change frequently, or which you foresee undergoing major changes in the future; snapshot those subvolumes before making changes, and make changes within the snapshot; if everything seems alright make the snapshot the new version of the subvolume the snapshot stemmed from. In any case, you should still make full system backups regularly, or at least back up your user data.

WonderWoofy · 2013-12-14 00:01:07

ANOKNUSA wrote:

In any case, you should still make full system backups regularly

Don't forget to test said backups.

Arch Linux

#1 2013-12-10 12:15:25

Recomendations for BTRFS

#2 2013-12-10 12:36:36

Re: Recomendations for BTRFS

#3 2013-12-10 13:08:57

Re: Recomendations for BTRFS

#4 2013-12-10 14:09:19

Re: Recomendations for BTRFS

#5 2013-12-10 14:59:23

Re: Recomendations for BTRFS

#6 2013-12-10 15:28:08

Re: Recomendations for BTRFS

#7 2013-12-10 15:57:12

Re: Recomendations for BTRFS

#8 2013-12-11 14:53:58

Re: Recomendations for BTRFS

#9 2013-12-13 11:52:50

Re: Recomendations for BTRFS

#10 2013-12-13 13:06:41

Re: Recomendations for BTRFS

#11 2013-12-13 13:46:10

Re: Recomendations for BTRFS

#12 2013-12-13 13:55:42

Re: Recomendations for BTRFS

#13 2013-12-13 16:02:35

Re: Recomendations for BTRFS

#14 2013-12-13 16:39:44

Re: Recomendations for BTRFS

#15 2013-12-14 00:01:07

Re: Recomendations for BTRFS

Board footer