[6.6] Track btrfs patches

[kakra]

Export patch series: https://github.com/kakra/linux/pull/31.patch

• Allocator hint patches: Allows to prefer SSDs for meta-data allocations while excluding HDDs from meta-data allocation, greatly improves btrfs responsiveness, file system remains compatible with non-patched systems but won't honor allocation preferences then (re-balance needed to fix that after going back to a patched kernel)

To make use of the allocator hints, add these to your kernel. Then run btrfs device usage /path/to/btrfs and take note of which device IDs are SSDs and which are HDDs.

Go to /sys/fs/btrfs/BTRFS-UUID/devinfo and run:

• echo 0 | sudo tee HDD-ID/type to prefer writing data to this device (btrfs will then prefer allocating data chunks from this device before considering other devices) - recommended for HDDs, set by default
• echo 1 | sudo tee SSD-ID/type to prefer writing meta-data to this device (btrfs will then prefer allocating meta-data chunks from this device before considering other devices) - recommended for SSDs
• There's also type 2 and 3 which write meta-data only (2) or data only (3) to the specified device - not recommended, can result in early no-space situations
• Added 2024-06-27: Type 4 can be used to avoid allocating new chunks from a device, useful if you plan on removing the device from the pool in the future: echo 4 | sudo tee LEGACY-ID/type
• NEVER EVER use type 2 or 3 if you only have one type of device
• The default "preferred" heuristics (0 and 1) are good enough because btrfs will always allocate from devices with most space first (respecting the "preferred" type with this patch)
• After changing the values, a one-time meta-data and/or data balance (optionally filtered to the affected device IDs) is needed

Important note: This recommends to use at least two independent SSDs so btrfs meta-data raid1 requirement is still satisfied. You can, however, create two partitions on the same SSD but then it's no longer protected against hardware faults, it's essentially dup-quality meta-data then, not raid1. Before sizing the partitions, look at btrfs device usage to find the amount of meta-data, at least double that size to size your meta-data partitions.

This can be combined with bcache by directly using meta-data partitions as a native SSD partition for btrfs, and only using data partitions routed through bcache. This also takes a lot of meta-data pressure from bcache, making it more efficient and less write-wearing as a result.

Real-world example

In this example, sde is a 1 TB SSD having two meta-data partitions (2x 128 GB) with the remaining space dedicated to a single bcache partition attached to my btrfs pool devices:

# btrfs device usage /
/dev/bcache2, ID: 1
Device size: 3.63TiB
Device slack: 3.50KiB
Data,single: 1.66TiB
Unallocated: 1.97TiB
/dev/bcache0, ID: 2
Device size: 3.63TiB
Device slack: 3.50KiB
Data,single: 1.66TiB
Unallocated: 1.97TiB
/dev/bcache1, ID: 3
Device size: 2.70TiB
Device slack: 3.50KiB
Data,single: 752.00GiB
Unallocated: 1.96TiB
/dev/sde4, ID: 4
Device size: 128.00GiB
Device slack: 0.00B
Metadata,RAID1: 27.00GiB
System,RAID1: 32.00MiB
Unallocated: 100.97GiB
/dev/sde5, ID: 5
Device size: 128.01GiB
Device slack: 0.00B
Metadata,RAID1: 27.00GiB
System,RAID1: 32.00MiB
Unallocated: 100.98GiB
# bcache show
Name Type State Bname AttachToDev
/dev/sdd2 1 (data) dirty(running) bcache1 /dev/sde2
/dev/sdb2 1 (data) dirty(running) bcache2 /dev/sde2
/dev/sde2 3 (cache) active N/A N/A
/dev/sdc2 1 (data) clean(running) bcache3 /dev/sde2
/dev/sda2 1 (data) dirty(running) bcache0 /dev/sde2

A curious reader may find that sde1 and sde3 are missing, which is my EFI boot partition (sde1) and swap space (sde3).

[Forza-tng]

Hi @kakra any chance to rebase against 6.7? The 6.6 patches do apply on 6.7 kernel, but with some offsets, so not a problem yet.

[kakra]

I'm only doing this for LTS kernels. Maintaining it for the fast moving kernel versions involved too much overhead in the past.

But yes, this one probably applies cleanly with some offsets to 6.7 and on. It applied without conflicts since 6.1 or even 5.19. I'm sure it will apply to 6.8, too.

[kakra]

added: type 4 for avoiding allocations on a disk, useful if you plan to remove the drive in the future, e.g. due to degrading performance or damaged sectors.

[kakra]

Added a patch to prevent a very rare and obscure corruption from reaching the disk, the file system will still flip RO but won't corrupt itself. Will be removed when upstream patches reach stable LTS.

[kakra]

Corruption fix patch is part of v6.6.50, dropped "validate dref root and objectid".

[kakra]

Obsolete, see #36 instead.