Btrfs

[oldgeek]

I have seen quite a few references to BTRFS on this forum and so decided to google it. OK, so now I know it's a Linux file system which replaces ext 4, but what I don't know are the advantages of BTFRS for someone like me, a generally casual user and occasional experimenter (I use Virtual Box to test different Linux OS and am not afraid to use disk partitioners with a little guidance). Would I notice the difference, and if so, what extra would I be able to do that I can't do now? I'm currently using a PC clone with an i3 processor and 4 GiB of ram--my HD is a dual-partition, with Kubuntu 16.04 (runs fine, no crashes) and Windows 10 (runs those few times I use it). How difficult would it be to switch over to BTRFS--would it be worth it? Mostly I'm just curious.

[Snowhog]

My uninformed opinion (I don't use btrfs); I still use ext4; is that for the casual "normal-every-day-user", btrfs is overkill. That said, and as stated, I'm really uninformed about btrfs. But oshunluvr and GreyGeek both use it, and like it a lot. They will have an answer for you.

[oshunluvr]

Short answer: probably not.

Major advantages are: subvolumes (no partitioning), send/receive (backups), snapshots (failed upgrade or bad installation protection), multi-device pooling (RAID and/or LVM replacement).

In general use (just my opinion) the two best-use cases are: Small single SSD or Multi-drive desktop/server.

With a small SSD, you can use subvolumes instead of partitions allowing all free spaces to be pooled (available) to all subvolumes obviating the need to guess at partition sizes. With a server or multi-disk PC you can take advantage of RAID capabilities and transmit (send/receive) and snapshots to make easy backups and protect yourself from bad upgrades, etc.

There are other benefits, like the fact you can add or subtract drives from a pool without taking it off-line, but for most casual users the above benefits are the greatest.

Specifically to your case: recently you had to re-partition your HD. Using btrfs, you would have only a swap partition and btrfs partition, thus allowing you to add or subtract subvolumes at will to the btrfs partition without any re-partitioning of drive space and the inherent dangers of that operation. I have 3 versions of Kubuntu and KDEneon installed to the same pool (2x256gb SSDs) each with its' own home and two extra subvolumes holding other data - all of which have the ability to expand and contract within the limits of the pool size and it happens without me having to do anything. Pretty sweet, right?

I backup by "sending" a read-only snapshot of a subvolume from this pool to a 2TB hard drive and it can be done easily via a cronjob or manually.

Most of these advantages are removed if you have a single but large hard drive.

[oldgeek]

Thanks for the info. My HD is 'only' 500 GiB (plus I have an external backup drive of 1 Tb and another of %00 GiB, which is full of old Kubuntu backup files, among other things) yet I manage to have 2 partitions plus 3 other OS on Virtual Box (KDE Neon, Peppermint 7 and Linux Mint 18) which I like to play around with. So far I haven't seen a need to change much (other than my recent re-partioning, which was successful though not always easy--I still don't know how I managed to boot Gparted from a USB and haven't been able to do it again) but I will copy the information you gave me in case I decide to try it out. After all, I'm retired and have plenty of time.

[GreyGeek]

.... I'm retired and have plenty of time.

I have only a single HD of 600GB and am retired like you ... plenty of time. I checked out the YouTube videos, and various anecdotals around the web. I found learning it was easy. Oshunluver had some excellent posts and I posted my installation and learning experiences on the forum. Searching for our names and btrfs will bring them up. A tool I found very useful is snapper. It is in the repository.
Using it's default configuration settings would eat up your drive space, so I modified the config file like this:
My "home" configuration:

# subvolume to snapshot
SUBVOLUME="/home"

# filesystem type
FSTYPE="btrfs"


# users and groups allowed to work with config
ALLOW_USERS="jerry"
ALLOW_GROUPS="jerry"

# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="yes"


# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"


# run daily number cleanup
NUMBER_CLEANUP="yes"

# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="5"
NUMBER_LIMIT_IMPORTANT="5"


# create hourly snapshots
TIMELINE_CREATE="no"

# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"

# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="0"
TIMELINE_LIMIT_DAILY="0"
TIMELINE_LIMIT_MONTHLY="1"
TIMELINE_LIMIT_YEARLY="5"


# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"

# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"

and my "root" configuration

# subvolume to snapshot
SUBVOLUME="/"

# filesystem type
FSTYPE="btrfs"


# users and groups allowed to work with config
ALLOW_USERS="jerry"
ALLOW_GROUPS="jerry"

# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="yes"


# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"


# run daily number cleanup
NUMBER_CLEANUP="yes"

# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="5"
NUMBER_LIMIT_IMPORTANT="5"


# create hourly snapshots
TIMELINE_CREATE="no"

# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"

# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="0"
TIMELINE_LIMIT_DAILY="0"
TIMELINE_LIMIT_MONTHLY="1"
TIMELINE_LIMIT_YEARLY="5"


# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"

# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"

In Kubuntu (and Ubuntu) a btrfs install creates two subvolumes, @ (/) and @HOME (/home). Other distros, like openSUSE create a dozen or more subvolumes on install and in my experience that complicates matters too much.

To make creating snapshots of / and /home a lot easier I wrote a script I titled "snap_pre_post.sh"

#!/bin/bash
# created by Jerry L Kreps on July 20, 2015 and released under the GPL 2.0.
# This script merely creates a snapshot in both root and home with the designation of PRE or POST as the type, 
# which indicates that the user created it before an action or afterwards.
# This script is run with PRE as the TYPE before an action which you may want to reverse
# AND this script run again with POST as the TYPE after that action has been completed.  Both snapshots are singletons because
# no timeline is used.  Only the "PRE" or"POST" in the description, along with a timestamp, links the pre to the post snapshot.
# To reverse the action run the following two snapper commands:
#
# snapper -c home udochange n..m   where n or o is the number of the PRE and m or p is the number of the POST snapshot
# sudo snapper -c root undochange o..p
#
# After running those two commands both of the empty snapshots folders can be deleted using
#
# snapper -c home delete n-m
# sudo snapper -c root delete o-p
#
#
#
NOW=$(date +%Y%m%d%H%M)
echo Enter snapshot type PRE or POST:
read TYPE
echo Enter description
read DESC
STR=$TYPE" "$DESC" "$NOW
echo $STR
HCMD='snapper -c home create -d "'${STR}'"'
RCMD='sudo snapper -c root create -d "'${STR}'"'
eval "$HCMD"
eval "$RCMD"