@pebcak I have always liked btrfs’s claims that it’s more crash resistant due to COW but I don’t know real life examples on home PCs. If it were me, I would use btrfs for that reason, there’s a good chance it will behave better than ext4.
And anyway, on my system I have only one btrfs partition and it’s not misbehaved yet.
Thanks so much for sharing your experience. I truly appreciate it. I am, as you surly have understood by now, quite new to many Linux related things and filesystems are no exceptions.
This is my first experiment/experience with btrfs and I have started reading a bit on the subject to understand better the basic design philosophy behind it.
I think I will go all-in btrfs. This is a new machine and this will be beginning of new experiences and incentive to learning more and new things.
Heading to Gparted…
You’re very welcome, enjoy!!
Thank you!
Here is how it looks like:
I have added this:
UUID=777ace92-81f4-44e0-b91b-f2ff42480739 /Data btrfs defaults,noatime,space_cache,autodefrag 0 2
to fstab for mounting the Data partition at boot. Is this alright or should I do it differently?
I use:
ssd not defaults:
I’ve seen this talked about as optimized mode on Arch forums, but not many people suggest it elsewhere so look it up if you want.
atime:
coz on my current main system (Neon) I use apt-btrfs-snapshot which needs atime to make older-than lists. It might be the same with some Arch btrfs tools so change it if something complains in this way.
compress=zstd:
it is lower compression but better performance than default btrfs compression, it was created for best of both worlds.
I think autodefrag is not recommended.
But I’m not an expert on btrfs…
You are correct @manuel it is also very bad for ssds.
This page has more info: https://wiki.archlinux.org/index.php/Btrfs
Thanks for the suggestions! I’ll look up those options. Got a lot of homework to do, it seems, when it comes to btrfs. And other stuff as well.
autodefrag
was used by default by the installer, so I thought I might as well use it on the Data partition as well. Here is the fstab:
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=7259-3050 /boot/efi vfat umask=0077 0 2
UUID=1a1b20eb-6fb5-46fc-9666-3b0e6f4c4300 / btrfs subvol=@,defaults,noatime,space_cache,autodefrag 0 1
UUID=1a1b20eb-6fb5-46fc-9666-3b0e6f4c4300 /home btrfs subvol=@home,defaults,noatime,space_cache,autodefrag 0 2
UUID=777ace92-81f4-44e0-b91b-f2ff42480739 /Data btrfs defaults,noatime,space_cache,autodefrag 0 2
Should I remove autodefrag
for the system partition as well?
@pebcak
autodefrag decreases the life of SSDs but increases btrfs perfomance in everyday use cases.
As Arch uses it as a default I assume they have weighed up the pros and cons.
BTW I’ve just read that noatime can significantly decrease snapshot size so I guess only use atime if you MUST.
autodefrag, noautodefrag
(since: 3.0, default: off)Enable automatic file defragmentation. When enabled, small random writes into files (in a range of tens of kilobytes, currently it’s 64K) are detected and queued up for the defragmentation process. Not well suited for large database workloads.
The read latency may increase due to reading the adjacent blocks that make up the range for defragmentation, successive write will merge the blocks in the new location.
man btrfs.5
Do you think I should leave it as is for the system partition and remove it for the Data partition?
noatime
under read intensive work-loads, specifying noatime significantly improves performance because no new access time information needs to be written. Without this option, the default is relatime, which only reduces the number of inode atime updates in comparison to the traditional strictatime. The worst case for atime updates under relatime occurs when many files are read whose atime is older than 24 h and which are freshly snapshotted.
In that case the atime is updated and COW happens - for each file - in bulk. See also https://lwn.net/Articles/499293/ - Atime and btrfs: a bad combination? (LWN, 2012-05-31).Note that noatime may break applications that rely on atime uptimes like the venerable Mutt (unless you use maildir mailboxes).
Then I’ll leave noatime
in fstab for the time being. I am not using anything that is relying on atime
that I am aware of. At least I haven’t had any “complaints” so far.
It seems that part of this weekend will be spent on reading up man pages for btrfs
I would leave autodefrag as is because:
- What I read talked about small databases such as FF uses being significantly worse without it.
- High writes on SSDs is not the significant worry it first was, things have changed such as spare space to replace failing areas, significantly longer MTBFs that surpass expectations, and not least NVME being a protocol to elevate SSDs in every way conceivable.
- Arch use it as default.
The logic to me is have it faster for 5 years or slower for 5 and a bit years? I’ve got 4 SSDs now coz the prices keep coming down, it’s just not a real world issue, it’s only really a server issue where ‘and a bit’ could be too expensive.
Have it faster for a bit less than five and and a bit years makes more sense. Thanks for the explanation!
i as well us this options in my fstab (also btrfs on a ssd):
subvol=@,defaults,noatime,space_cache,autodefrag,compress=zstd
that’s for the root subvolume as an example.
Great! Thanks for the input!
This I should add to my entries as well. I remember now that it was mentioned by @robgriff444 as well further above.
Thanks for the input!
compress=zstd
In comparisons side by side against default (lzo) zstd won but you probably wouldn’t notice it, it isn’t that much faster, it’s just advancing the technology for PC use cases because servers use best compression to reduce the total number of data drives and consequently employ expensive cacheing drives to bring the performance up to requirements, it’s just the cost-effective consensus.
When it comes to restoring from a Timeshift snapshot, should I chose the snapshot boot entry from Grub menu and once I am in the system run Timeshift and restore the system? And then reboot and choose the “normal” boot entry and the system is restored to a previous state?
Yes, I done it this way twice when I needed to without issue.