BTRFS - why you should or should not

"Off-topic" but Linux related discussion, about ARCHLabs or other distributions.

Moderator: Founder

BTRFS - why you should or should not

PostPosted by HarronV » Tue Jun 27, 2017 6:50 am

BTRFS is a filesystem which is getting more and more common. And I for me have chosen to use it for several reasons:

1. It is fast (CoW = Copy on Write ... built in Write-Caching to an extraordinary extent)
2. It is expandable and shrinkable, reusable and secure (in matter of data-loss)
3. It has a very elegant way of managing snapshots (with the above mentioned CoW)

Point 1 and 3 go hand in hand. To backup your current system state of "/" in "/.snapshots/1" just use:
Code: Select all
# btrfs subvolume snapshot / /.snapshots/1
and voila you have an immediate copy ... no matter how much data you are backing up. In fact, the Filesystem does not copy anything. But when you make changes to the original system, these changes will be written to a new file. So you have no drawback in time.

For #2:
Creating a BTRFS-Volume is very handy:
Code: Select all
# mkfs.btrfs -f -L FooDrive /dev/sdb1 /dev/sdc1
This creates a BTRFS RAID0/1 partition which is treated like one single blockdrive. You are able to create new partitions (named subvolumes) in this or a single partition-BTRFS-concept.
If you are expanding your system with a new drive, then a command like:
Code: Select all
# btrfs device add /dev/sdc1 /home
will add the new storage to the existing /home-volume. And it is converting your system automatically into a RAID0/1 ... you just need to run once the balance-command:
Code: Select all
# btrfs balance start /home

Removing a drive/partition from such a RAID-scheme is just an one-liner again:
Code: Select all
# btrfs device delete /dev/sdc1 /home
Both, balancing and removing a device takes some time ... be patient and you might want to watch the progress in a seperate terminal:
Code: Select all
$ sudo watch btrfs fi show

For working with BTRFS advantages, subvolumes should be created:
Code: Select all
# mount /dev/sdb1 /mnt
# btrfs subvolume create /mnt/ArchLabs-root

More here: ... nux-part-1 and there

#1 You should have some knowledge about setting up the fstab before thinking of using BTRFS in a production environment, as most Linux distributions ar far from using BTRFS correctly. And manual manipulations of the filesystems/partitions are mandatory.
#2 In case of making a fresh install of ArchLabs on BTRFS, be aware that the Calamares Installer ignores premade subvolumes or RAID-Systems and just wipes everything on the selected partition.
If you want to convert an existing installation, here is an excellent guide: ... u-12.10-p2
Either way, plan your partitioning scheme ... as a btrfs-partition can be partitioned itself, you might end up having two or three distributions on one. If you like to hibernate, you might want to have one Swap-partition for each installed Distribution.
#3 ArchLabs by default overwrites the mount command, this can result in funny moments, when booting into a rescue system. So after the first boot into ArchLabs you want to modify the .zhrc and .bashrc of your account and of root ... rename the mount command with something more specific, I use mountct.

Have fun,
User avatar
Posts: 36
Joined: Wed Jun 07, 2017 6:36 pm
Running Release: installing 4.1

Re: BTRFS - why you should or should not

PostPosted by erikdubois » Wed Jun 28, 2017 8:21 am

We keep it in mind.
We follow up what calamares can do for us.
Living to learn, learning to live.
Linux fits well in my life's motto.
More info on
Archlabs support articles are on
Archlabs support youtube channel is on
User avatar
Site Admin
Site Admin
Posts: 333
Joined: Sun Mar 05, 2017 5:42 am
Location: Belgium

Return to ArchLabs and General Linux Discussion

Who is online

Users browsing this forum: No registered users and 0 guests