Arch Linux

mine_diver

Member

Registered: 2024-03-18

Posts: 60

Optimal BTRFS options

Hello!

Recently, I've reinstalled Arch Linux since I started having some issues due to invasive Plasma theming and just generally wanted to change some things about my disk layout.
I have 2 500GB M.2 NVMe SSDs and a 2TB HDD, so I've decided to LUKS encrypt all storage with the same password (so I only have to enter it once during boot thanks to sd-encrypt),
and setup btrfs raid0 data and raid1 metadata on the two SSDs, as well as used compress=zstd:15 on the SSDs and compress=zlib:9 on the HDD to maximize storage and reduce access to the disks.
My CPU is Intel Xeon E5-2667 v4, my RAM is ECC DDR4 64GB, my use case is:
1. Programming (mostly IntelliJ IDEA)
2. Gaming (Minecraft, Cyberpunk, Team Fortress 2, and a few more titles)
3. Occasional VMs (mostly Windows, be it 7 for nostalgia reasons or 11 for MS Office)

However, now I'm uncertain about how optimal this setup is.

1. Raid0
As I see it, if I already provide redundancy via timeshift to the 2TB HDD, there's no point in sacrificing fast storage for raid1 data.
So that leaves 2 options - single and raid0. As far as I understand, raid0 is objectively better in this case, since, even if only slightly, it does increase IO performance.
And if either of the disks fails completely, both single and raid0 wouldn't be fully recoverable, and there's no reason to dig into the survived drive
since either way there are full backups readily available on the 2TB HDD.
I'd like to know if my understanding is correct here.

2. compress
After setting up compression, I saw multiple remarks that btrfs's default compressibility check is rather bad since it only checks the first block,
so compress-force should be the preferred option by default. Is this correct? Would compress-force skip compression if the end result was larger than the original file?
Should I switch both the SSDs and the HDD to compress-force?

3. zstd:15
From what I understand, zstd is the best balance between compression ratio and performance, so I've decided to max it out on SSDs.
However, I also saw multiple performance benchmarks suggesting that writes are getting incredibly slow approximately past level 8 for very diminishing returns.
Is zstd:3 truly the best default? Or will the performance impact not really be noticeable in my specific use case (because, so far, I haven't really noticed anything significant)
so I could just keep on using zstd:15?

4. zlib:9
Since the HDD is mostly for cold data and backups, maximizing the compression ratio is the top priority. Is zlib:9 the best in this case?

Would love to hear some feedback.

-thc

Member

Registered: 2017-03-15

Posts: 775

Re: Optimal BTRFS options

Since you have backups available (and don't need redundancy), just try the scenarios (RAID0, single, compress-force, algorithm). Each use case and hardware combination is different and you read vastly different opinions. Take a disk I/O heavy test run and check the different setups for possible gains.

What I'm curious about is the disk encryption. I've read this this so often in this forum that it's slightly bugging me.
What is your rationale for adding this layer of complexity?

Last edited by -thc (2024-12-24 07:52:00)

agapito

Member

From: Who cares.

Registered: 2008-11-13

Posts: 679

Re: Optimal BTRFS options

If you want to reduce hard disk accesses, you have chosen the worst possible file system and also the least recommended when using virtual machines.

Why do you want to use file compression? If you don't desperately need more available space, it's a waste of resources, especially on a CPU like yours that is not very strong in single-threading.

Anyway, if you want to use compression, my rule of thumb is zstd:1 for NVMe, zstd:3 for normal SSD and zstd:5 for HDD. Compress-force option will use more CPU time in exchange for extra space savings around 10%.

---

Excuse my poor English.