Partitioning for Btrfs

General system
#1

I have now switched my system to btrfs, everything seems to run cleanly. However, I am not sure if I have created the partitioning correctly. Starting point is a 256 GiB SSD, on which nothing else will be (/home with data is on a HDD), therefore the much too large / -partition, but never mind. When I created the / -partition, it automatically created a subvolume for /var/cache and /var/log. I created the swap as primary. Everything works fine so far. Just want to hear from you experts if I can leave it like this or if there is still room for improvement. Are subvolumes absolutely necessary with btrfs? Here is my fstab:

# <file system>                           <mount point>  <type>  <options>                                                            <dump>  <pass>
UUID=6B27-4ECC                             /boot/efi      vfat    umask=0077                                                           0       2
UUID=e8267b53-a196-4ce5-bd51-6481d3ed65ff  /boot          ext4    defaults,noatime                                                     0       2
UUID=d4ea77de-a2db-42c2-aca9-10bb58f70661  /              btrfs   subvol=/@,defaults,noatime,space_cache,autodefrag,compress=lzo       0       1
UUID=d4ea77de-a2db-42c2-aca9-10bb58f70661  /var/cache     btrfs   subvol=/@cache,defaults,noatime,space_cache,autodefrag,compress=lzo  0       2
UUID=d4ea77de-a2db-42c2-aca9-10bb58f70661  /var/log       btrfs   subvol=/@log,defaults,noatime,space_cache,autodefrag,compress=lzo    0       2
UUID=76c9bf53-88a4-4d70-8949-b23a590140a8  /home          ext4    defaults,noatime                                                     0       2
UUID=2d8c57a0-3705-430c-ad9b-4f368e4d7b6f   none          swap    defaults                                                             0       0
tmpfs                                      /tmp           tmpfs   defaults,noatime,mode=1777                                           0       0

Edit: autodefrag for an SSD makes me think a bit …

#2

They aren’t absolutely needed but they are useful and have no real downsides. Generally speaking, more is better. With separate subvolumes, you can create separate snapshot policies for each subvolume. Since they share the same partition, there shouldn’t be any concerns with more.

For example, you probably don’t want any snapshots on /var/cache. On /var/log you probably want a snapshot policy with minimal retention. For other parts of the OS, you might want a little more retention.

It is all a matter a personal preference. I generally have many subvolumes for convenience purposes.

Honestly, I think the biggest mistake is putting /home on an HDD. There is lots of cache access and frequently accessed files in /home. You generally want that on you highest performance storage.

I would consider migrating /home to a subvolume on your SSD. Then mount your HDD somewhere else and use bindmounts or symlinks to keep Documents, Videos, Music, etc on the HDD.

2 Likes
#3

Ok, thx, and what’s about autodefrag (on SSD)?

#4

I haven’t done excessive research but I don’t see any obvious reason to enable autodefrag on an SSD.

1 Like
#5

My point is that it is always advised against defragmenting an SSD. In this case autodefrag was automatically enabled, but I think I take it out of the fstab again

#6

I guess <pass> needs to be set to 0 if my reading of the following is correct:

https://btrfs.wiki.kernel.org/index.php/Manpage/fsck.btrfs

It is indeed set to 0 in my Fedora installation which uses Btrfs as the default filesystem.

1 Like
#7

Ok, I can’t tell from the text there, but good. You’re the expert :slight_smile:

#8

Basically what the text says is that a non-zero value means that the filesystem is checked for inconsistency at every boot. This is not needed for Btrfs.

In case of doubt, wait for the real ones to chime in :blush:, but hey, thanks anyway :slightly_smiling_face:

1 Like
#9

0 means no file system check. Why?

#10

OK, understand

1 Like
#11

Sheldon Cooper?

2 Likes
#12

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

#13
4 Likes
#14
#15

Danke Joe! :ok_hand:t2:

#16

OpenSUSE uses btrfs as a default filesystem for a long time, and it has quite extensive default subvolume layout. It has separate subvolumes for /boot/grub2/x86_64-efi, /home, /root, /opt, /srv, /tmp, /usr/local, /var. You can find the reasoning for why they make each of this separate subvolumes in this article: https://en.opensuse.org/SDB:BTRFS.

Just don’t create /boot/grub2/x86_64-efi subvolume in EndeavourOS, or you won’t be able to boot.

2 Likes
#17

I did this quite simply with my installation: / on a partition, Calamares then created subvolumes for /var/cache and /var/log/ independently during the installation. /boot is ext4 on its own.

#18

@joekamprad : Now what exactly is the difference between your method of rearranging Calamares before the installation in the live system and the method of the previous partitioning with Gparted? Possibly something is missing then? I have prepared the partitions with Gparted and then formatted in btrfs first during the installation with Calamares. It all works, I’m a little confused …

#19

i do not say it will be better to use setting BTRFS as default for calamares, it will only be automatic so by changing a word in a single file, could be more simple to use if you do not want to manually setting it up post install :wink:

#20

Hm, I did not set up anything AFTER the installation. Reboot and good. What would have been to do? Or better asked, what is still missing from my setup? If this gets too convoluted, I’ll reinstall using your method to make sure everything is ok.