RFE - Beginners guide to BTRFS

[©TriMoon™]

Hi all,
First off: I'm a total noob when it comes to BTRFS as i have never used it.
But it somehow got my attention while browsing these forums.

While reading the mentioned guide i noticed some bad info and because that thread is closed i could not reply to it, thats why this new thread

I noticed a mentioning of /lib/systemd/system/fstrim.timer and /etc/systemd/system/timers.target.wants/fstrim.timer and even a post trying to edit that last file.
Here comes the correction to the bad info related to these files:

• You should never need to access /etc/systemd/system/timers.target.wants/fstrim.timer because it is only a symbolic link to the actual file used...
• The correct way to adjust settings related to any unit as an administrator is to use "systemctl edit <unitname>" (See: systemctl(1))

So the correct way to adjust the frequency that fstrim.service runs is to:

sudo systemctl edit fstrim.[B]timer[/B]

And put the below inside the file that gets created (By default = /etc/systemd/system/fstrim.timer.d/override.conf)

[Timer]
OnCalendar=
OnCalendar=monthly

The "OnCalendar=" clears the previous frequency, if you don't use that then it will run "monthly" additionally to the pre-configured value(s).
You can check the configs applied using: (which in my case produces)

> systemctl cat fstrim.timer

# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/fstrim.timer.d/override.conf
[Timer]
OnCalendar=
OnCalendar=monthly

And to check the actual used timers for the fstrim.service: (I removed my override.conf and it's directory)

> systemctl list-timers fstrim

NEXT                        LEFT        LAST                        PASSED        UNIT         ACTIVATES     
Mon 2020-08-03 00:00:00 +03 5 days left Mon 2020-07-27 00:00:03 +03 1 day 14h ago fstrim.timer fstrim.service

1 timers listed.
Pass --all to see loaded but inactive timers, too.

All that said, BTRFS looks very interesting and im sure i will try it one day.

[GreyGeek]

You can't go wrong with BTRFS!

I began fiddling with BTRFS with the 14.04 release but never got serious with it until the 16.04 release. BTRFS was evolving rapidly and I started that initial BTRFS post in the summer of 2018 as a place to put info relevant to my usage as that info changed.

So, jump in with any corrections, changes and additions you want to make. You won't hurt my feelings. I'd make one recommendation and that is to add a link in your post to the last post in the BTRFS thread and continue making any additional post you feel necessary to this thread.

I also started it as a place to encourage BTRFS and to answer any questions that I could about problems folks were having with it as they jumped on board. I was surprised to find out that Oshunluver and others were using it for longer than I have been and were better informed and were more sophisticated about its use than I am.

Intitally I began using the Systemd GUI to edit systemd files and make changes, but the developer of that GUI dropped support for it and it hasn't been added to 18 or 20.04. It didn't matter to me because I make all my changes via the terminal, and ditto for snapshots and their manipulations.

I noticed that the last post in that thread was in October of 2018, so it has been inactive for two years. Or, perhaps, one of the admins will unlock the thread so your post can be moved to there and your continued additions can be added there.

Meanwhile, you have to give BTRFS a try. It is absolutely awesome!

[mr_raider]

Ok why does a TRIM on btrfs partition take so much longer than an ext4 partition?

[oshunluvr]

No offence, but who's timing trim? I mean is that an issue? By default trim runs in the background on a cron job, so why care?

EXT4, according to it's creator, is an out-dated stop-gap file system waiting for a better replacement. BTRFS and EXT4 have little in common, meaning they do very little the same way so I would expect various housekeeping chores to differ in function and timing. Of course, you're free to use whatever file system you want.

[©TriMoon™]

You can't go wrong with BTRFS!

I began fiddling with BTRFS with the 14.04 release but never got serious with it until the 16.04 release. BTRFS was evolving rapidly and I started that initial BTRFS post in the summer of 2018 as a place to put info relevant to my usage as that info changed.

So, jump in with any corrections, changes and additions you want to make. You won't hurt my feelings. I'd make one recommendation and that is to add a link in your post to the last post in the BTRFS thread and continue making any additional post you feel necessary to this thread.

I also started it as a place to encourage BTRFS and to answer any questions that I could about problems folks were having with it as they jumped on board. I was surprised to find out that Oshunluver and others were using it for longer than I have been and were better informed and were more sophisticated about its use than I am.

Intitally I began using the Systemd GUI to edit systemd files and make changes, but the developer of that GUI dropped support for it and it hasn't been added to 18 or 20.04. It didn't matter to me because I make all my changes via the terminal, and ditto for snapshots and their manipulations.

I noticed that the last post in that thread was in October of 2018, so it has been inactive for two years. Or, perhaps, one of the admins will unlock the thread so your post can be moved to there and your continued additions can be added there.

Meanwhile, you have to give BTRFS a try. It is absolutely awesome!

I've done as you suggested to my OP.
And yeah i'm exited to try it out, these days i'm using an oem-setup to re-install my system with my own script-system that i run after logging into the oem-setup for finetuning/changes/installs., so i'm exited to try it.
My current Disk setup is as follows:

sda (4TiB)
├──p1 ESP   ( 550 MiB, fat32)
├──p2 swap  (  64 GiB)
├──p3 /tmp  (   8 GiB, ext4)
├──p4 /home (  64 GiB, ext4)
└──p5 /srv  (~3.5 TiB, ext4)
sdb (Currently disabled in bios)
└── M$ Windows 10 enterprise (Pirated, for occasional M$ gaming >:D)
sdb (150GiB, will become sdc when above enabled)
├──p1 Kubuntu (64 GiB, ext4)
├──p2 Space for extra distro (64 GiB, ext4)
└──unallocated at moment...

"/srv" is where most of my important files are and is not in fstab, but gets auto-(un)mounted using systemd.
I plan on doing the same with "/home" as an overlay but have not found a way yet (doing other stuff)

Oh and final note: Im booting in SecureBoot using Systemd-boot

[GreyGeek]

A 4TB drive, uh! *envy*

Your partitions:

sda (4TiB)
├──p1 ESP   ( 550 MiB, fat32)
├──p2 swap  (  64 GiB)
├──p3 /tmp  (   8 GiB, ext4)
├──p4 /home (  64 GiB, ext4)
└──p5 /srv  (~3.5 TiB, ext4)
sdb (Currently disabled in bios)
└── M$ Windows 10 enterprise (Pirated, for occasional M$ gaming >:D)
sdb (150GiB, will become sdc when above enabled)
├──p1 Kubuntu (64 GiB, ext4)
├──p2 Space for extra distro (64 GiB, ext4)
└──unallocated at moment...

Two of your partitions are necessary for WIndows 10, but a separate partition for /home and /srv isn't really required using BTRFS. And, BTRFS doesn't use a swap space but some applications may need it. And, /tmp isn't necessary either.

One of the features of BTRFS is that on the drive or partition it is installed on its <ROOT_FS> is one giant pool that can encompass the entire drive. So, @ and @home are subvolumes in that pool, created by default when one chooses "/" as the install point, and each draws according to its needs and do not have to be sized before the install, thus avoiding the problems of not giving a subvolume too much size (and wasting disk space) or not giving it enough (and running out of space). That's why BTRFS works best if given the entire drive, sans partitions.

So, for most users, creating a separate home partition during the install defeats one of the strengths of BTRFS.

When one mounts the <ROOT_FS> to, say, /mnt, the structure is
/mnt/@
/mnt/@home
Personally, I create a subdirectory called snapshots into which I store my @ and @home stapshots.
/mnt/snapshots

One can mount /mnt
mount /dev/disk/by-uuid/ce2b5741-c01e-4b3d-b6ba-401ad7f7fcdf /mnt
and create and delete snapshots while the system is running. ALWAYS use the UUID to mount a BTRFS subvolume, not /dev/sdX.

One can also mv @ to, say, @old and mv @home to @homeold, then use the btrfs snapshot command, without the "-r" parameter to copy a /mnt/snapshots/@yyyymmdd snapshot to @ and a /mnt/snapshots/@homeyyyymmdd to @home, and then reboot, reverting to the yyyymmdd snapshot pair.

Recently I was experimenting to see how well Kubuntu 20.04 would run on top of ZFS. ZFS is not an option in the Kubuntu installer so I installed qemu & kvm (virt-manager, et. al), and created an Ubuntu 20.04 VM with ZFS as the <ROOT_FS>. Then, from Ubuntu's repository, I installed kde-desktop. Kubuntu ran well on top of ZFS but the features that ZFS added weren't sufficient to lose the features that BTRFS has. Anyway, I created a 60GB static HD to prevent problems that BTRFS has with dynamic databases and VM drives. (Yup, I used "chattr -R +C /var/.../images" to help but a better way, which I've also used, is to use the BTRFS resize command to shrink the <ROOT_FS> by 6GB. Then boot into a LiveUSB and use gparted to shrink the BTRFS by 60GB and create an EXT4 partition out of it for the VM. Later, when I was finished I booted into a LiveUSB and used gparted to check the drive, which you have to do in order to use the gparted resize-delete command, and resized the drive to give the whole thing back to BTRFS again. I also rolled back to the snapshot previous to the VM & ZFS+Kubuntu snapshot and rebooted. Then I used the BTRFS resize command to expand the <ROOT_FS> out to take the entire drive again.

In the nearly 5 years I've been using BTRFS I've never had a single problem, and I've played with about every possible configuration and raid level, which is one reason why I installed 3 HDs in my laptop.

Another thing I did for a while was to create a subvolume labeled @data under /mnt.
In the fstab I mounted it to /home/jerry/data and stored its snapshots in /mnt/snapshots as well. I used it the way you probably use /srv.

If one opens a terminal and used mc to browse the snapshots one can dive into @, for example, and see that /home in @ is empty. One cannot create a subvolume inside a subvolume, which is why you don't see @home inside @. While browsing @ or @home, or any particular @ or @home snapshot, one can copy a file or folder out of the snapshot and back into the system, or the other way around. So, if you inadvertently delete a file or folder you can browse the most recent snapshot and copy it out of the snapshot and back into the live system without having to rollback to a snapshot.

Another thing I like about BTRFS is incremental backups. One can copy a snapshot to a remote storage device using BTRFS send & receive. Suppose a USB HD, formatted as BTRFS, is plugged in and mounted to /backup
btrfs send /mnt/snapshots/@yyyymmd1 | btrfs receive /backup
btrfs send /mnt/snapshots/@homeyyyymmd1 | btrfs receive /backup
will copy the yyyymmd1 snapshots of @ and @home to /backup. The time it takes depends upon the size of the subvolumes but using mine, 50GB for @ and 110GB for @home, a send & receive takes about 10 min + 15 min = 25min, +- 5min.
Now, at day d2 one can take advantage of the d1 snapshots on /backup by doing
btrfs send -p /mnt/snapshots/@yyyymmd1 /mnt/snapshots/@yyyymmd2 | btrfs receive /backup
btrfs send -p /mnt/snapshots/@homeyyyymmd1 /mnt/snapshots/@homeyyyymmd2 | btrfs receive /backup
and the time taken is about 15secs + 25seconds = 40secs
because only the differences between d1 and d2 are sent and the receive part of the command uses the d1 snapshot it has to create the d2 snapshot and populate it with the additions sent by the send command. The neat thing is that it really doesn't matter how many days about d1 and d2 are. But, the greater the changes between d1 and d2 the longer the incremental backup will take.

Oshunluver has a series of excellent posts explaining how to use grub to install or remove distros and boot into any distro at boot time by choosing that distro from the grub menu.
https://www.kubuntuforums.net/showth...l=1#post413900

[©TriMoon™]

Yea i have read some posts with scripts that auto detect isos to boot using grub etc...

But yea well there is a little problem here and thats i want to separate the OS install from my data (home and srv) so that i can reinstall the OS without any losses and even use them via another distro install...
Thats why i have my Kubuntu on a separate drive and partition as the rest...
My /home is mostly my desktop setup with my settings etc and a very few personal scripts.
My /srv is where i keep my WebServer, DNS, and software development etc...
I know i don't actually need the swap or /etc with 32GB ram but ahh well things happen...

The best part of BTRFS i like so far reading about it, is the backup/restore functionality while online.

Oh and ps: My windows is on a separate disk that is disabled at moment, it has it's own ESP, i only use it very very seldom and if i do i disable the rest and enable the M$ one to keep it's paws off of linux > as much as possible..

[mr_raider]

Yea i have read some posts with scripts that auto detect isos to boot using grub etc...

But yea well there is a little problem here and thats i want to separate the OS install from my data (home and srv) so that i can reinstall the OS without any losses and even use them via another distro install...
Thats why i have my Kubuntu on a separate drive and partition as the rest...
My /home is mostly my desktop setup with my settings etc and a very few personal scripts.
My /srv is where i keep my WebServer, DNS, and software development etc...
I know i don't actually need the swap or /etc with 32GB ram but ahh well things happen...

The best part of BTRFS i like so far reading about it, is the backup/restore functionality while online.

Oh and ps: My windows is on a separate disk that is disabled at moment, it has it's own ESP, i only use it very very seldom and if i do i disable the rest and enable the M$ one to keep it's paws off of linux > as much as possible..

By default Ubuntu variations installed to a single btrfs partition will separate into two subvolumes root (@) and /home (@home).

You can always reinstall and recover your home subvolume. You can play around in a virtual machine and try it out.

[jlittle]

... i want to separate the OS install from my data (home and srv) so that i can reinstall the OS without any losses and even use them via another distro install...

If you put everything, multiple distros and home directories, except the ESP and possibly a swap, in the same btrfs, all those things can still be kept separate, in separate subvolumes, and all share the same free space. (I presently have 5 installs.)

Not having to juggle partitions is a huge time saver. As well, all my installs and most of my data can easily fit on my smallish SSD. It's easy to "reinstall the OS without any losses", I do it often when testing new releases.

A drawback may be the single point of failure, the btrfs, for all the installs.

[GreyGeek]

One of the reasons why I prefer the AppImage version of a package is that every library and file that it needs is in the AppImage package itself, and it is run by making it executable and clicking on it. It is deleted by merely deleting the AppImage file.

A lot of applications sprinkle their files and libraries around the system. Some things go into /usr/lib, some into /opt, some into /usr/bin, etc...., which some parts go into the /home/acct. If one doesn't keep the @ and @home snapshots linked then it is possible that a @ is installed which doesn't have the libraries or binaries of a package that has some components installed in the home account, and sometimes a @home subvolume not having the application wouldn't be able to communicate with the application components in the @ subvolume. That's why I back up @ and @home as snapshot pairs using the same suffix as part of the snapshot name.

Simply creating a @data subvolume and mounting it in fstab at /home/acct/data is the same as having srv on another partition or drive, except that you can snapshot it instantly and you can use the send & receive functions to send the snapshots to other storage mediums. If you don't want to use BTRFS on those mediums you can use the -f parameter in the send command which will send the stream as an ASCII file. From the 1st post in the BTRFS forum:

IF your destination is not formatted with BTRFS then your send command should be:
btrfs send /mnt/snapshots/@_basic_install -f /media/@_basic_install.txt
where /media is a mounted USB stick formatted with EXT4 or FAT32, or a network destination.
The "-f" option sends the subvolume to the destination as a stdout file, i.e., ASCII.

To convert it back to a subvolume one would use:
btrfs receive -f /media/@_basic_install.txt /mnt/snapshots
The received subvolume will be set to read-only. To add the write attribute use
chmod u+w /mnt/snapshots/@basic_install.txt
To remove the txt extension use
mv /mnt/snapshots/@_basic_install.txt /mnt/snapshots/@_basic_install

[©TriMoon™]

I find it kinda scary to have everything on a single physical disk, but i guess the snapshot/backups functionality is exactly for that...
(And thats the biggest part of BTRFS that got my attention in the first place)

When it comes to desynced OS/HOME configs, thats why i use my own script system (Which is on the /srv partition), to re-install everything i use after an oem-install of the OS...
I dunno still kinda hesitant to switch FS's

Any tips how i could migrate my setup without any risk of loosing access to all my data in /home and /srv ?
I don't have spare HD's but i do have DVD's i could write to...

Oh ps: Does BTRFS support fileacl's set using setfacl?

[mr_raider]

I find it kinda scary to have everything on a single physical disk, but i guess the snapshot/backups functionality is exactly for that...
(And thats the biggest part of BTRFS that got my attention in the first place)

That is true. BTRFS will not protect you from hardware failure of a single drive. That is what backups are for. If you have a valid reason to keep home on a separate physical drive (i.e. tons of media files) go ahead. But in that case I would just mount the media drive somewhere convenient and keep /home and / on my fastest storage medium.

Subvolumes allow you to segregate / and /home on the same drive. For the compulsive distro hopper, you can have multiple physical installs on the same drive and switch them as needed.

For example, my home laptop has only one nvme SSD that's 512GBs. It ran KDE neon 18.04 base for 2 years. I wanted to try Neon 20.04. So when I booted teh live CD, I mounted my drive and renamed the two level 5 subvoluems from @ and @home to @1804 and @home1804. Then I had teh installer target the same drive with no formatting. My 20.04 isntall is now in @ and @home, and the old install is untouched.

You can now boot into the new 20.04 install and try it out. If I don't like it, I wipe the 2 new subvols and rename the old ones back.

In an EFI install it's even possible to change the boot OS by editing EFI/ubuntu/grub.cfg

[oshunluvr]

BTRFS will not protect you from hardware failure of a single drive.

Preach!

I find it kinda scary to have everything on a single physical disk,

But this has nothing to do with the file system. One could make an argument that by having everything on a single file system adds a small amount of risk but IME rarely is a disk fault limited to a single partition. Bad sectors are handled fairly well these days and drives are much more robust than they used to be. My HDD with 62000 power-on hours and zero reallocated sectors say so.

but i guess the snapshot/backups functionality is exactly for that...
(And thats the biggest part of BTRFS that got my attention in the first place)

Bingo! The clear advantages here: Subvolumes allow segregation of data without imposing partition boundaries, thus free space is dynamically allocated. Subvolumes allow snapshots and backups and can be configured to your liking. The default *buntu install is "@" for root and "@home" for home, but like mr_raider I have currently 5 distros/3 homes on my desktop and 2 of each on my laptop.

I also have a media server with 3hdds totaling 22TB. I use subvolumes for each media type (moveis, tv shows, etc) and back them up separately.

[jlittle]

Oh ps: Does BTRFS support fileacl's set using setfacl?

Yes. A few file attributes (chattr), aAcCdDiSX, and unlimited extended file attributes (setfattr) as well.

[GreyGeek]

http://manpages.ubuntu.com/manpages/...setfacl.1.html

If you have mlocate installed then you can do
locate bin/set

and

locate bin/get

to see a list of getters and setters used by Ubuntu.