Special considerations for btrfs + bcache?

Ask Fedora
,
1

I am going to rebuild my 8T sata disk. My system will be like:

/dev/sda1 - 600MB efi
/dev/sda2 - 400GB bcache
/dev/sda3 - 1G /boot
/dev/sda4 - 500GB btrfs for Silverblue/Kinoite

/dev/sdb1 - 600MB efi
/dev/sdb2 - 20GB for emergency OS
/dev/sdb3 - 8TB btrfs bcache backing partition

/dev/sdc1 - 6T btrfs (to receive btrfs send from /dev/sdb3)

Under normal situation, I will boot with my SSD (sda) and access sdb3 via bcache .

In emergency, I still want to access sdb3 when booted with /dev/sdb2 .

Wtih this setup, will btrfs dedup work transparently with out regarding to bcache?

=== Questions ===
Q1: with bcache, should I use 1 or 2 copy of metadata?
SSD: metadata 1 copy
HDD: metadata 2 copy

Q2: For compress mount options, should I use zstd:1 or zstd:5 ?

1 Like
2

Bcache is a Linux kernel block layer cache.

It allows one or more fast disk drives such as flash-based solid state drives (SSDs) to act as a cache for one or more slower hard disk drives.

1 Like
3

Yes, exactly, I want to use the 400GB ssd partition as a fast cache of the 8T data volume.

4

Reliability is critical for anything that does writeback caching; if it breaks, you will lose data

Btrfs delayed allocation tends to combine small random writes into larger sequential writes anyway, so there may not be a significant boost in performance by using an SSD as cache, depending on the workload and depending on the cache settings.

If you expect a file system to survive crashes, no matter the failures of the SSD caching device, you need to use write through caching, i.e. writeback is off. Since writes must be stable on the backing device in write through mode, you lose the benefit of caching for writes, but you still get them for reads.

If you enable writeback caching, and the SSD doesn’t consistently honor flush/fua, and you happen to get an ill timed crash or power failure, the file system will be lost.

There is a non-subtle complexity with additional layers. Not just the software layers, but when combining SSD and HDD which have ambiguous and invisible firmware behavior.

2 Likes
5

As a start, I will use the writearound policy by default while learning more about this setup.

This volume will be mainly storing my family photos and video clips.

Initial task is to consolidate all of them into a single place, using btrfs send to backup.

Then re-organize the photos/videos by:

  • date of creation (to allow me to store them to smaller disks by date)
  • then by Camera (it will indicate who takes the photo easily)

After they are sorted, then for each year or month, do file level dedup

  • first to remove binary duplicates
  • then to remove visual similar (by Shotwell or Digikam)

Finally, to publish via some webpage (only accessible inside my family LAN), so that they can be accessed easily. (Not sure what to use at the moment)

I think when doing the sorting (using exiftool), I will enable writeback temporary.