2

I have set up /dev/sda3 on my SSD to cache /dev/sdb3 on my HDD as /dev/bcache0 using bcache in Ubuntu 13.10 (kernel 3.11.0-14-generic). I have formatted it as ext4.

I currently mount / (on my SSD) and /home (bcache) using these fstab options

# / (root) -> /dev/sda2 (SSD)
UUID={uuid for /dev/sda2}   /  ext4  discard,noatime,nodiratime,errors=remount-ro   0  1

# /home -> { /dev/bcache0 -> { /dev/sda3 -> /dev/sdb3 } }
UUID={uuid for /dev/bcache0}  /home  ext4  defaults   0  2

What I am wondering is if any mount options (e.g. discard (TRIM), noatime, etc) are useful when mounting bcache, or if bcache its self takes care of optimising the filesystem for the SSD and HDD partitions.

Please let me know if I have not made my question clear, thanks.

MattSturgeon
  • 262

3 Answers3

1

discard is a special case: bcache will (I think) make use of it to discard sectors, but won't pass it down the stack unless you have explicitly asked it to (echo 1 |sudo tee -a /sys/block/*/bcache/discard, which will be remembered across reboots). The best case for performance is that your filesystem sends discards (which means you need to put the flag in /etc/fstab) and bcache passes them down if and only if your SSD is SATA 3.1 (queued TRIM support).

Your filesystem is able to detect bcache as something like an SSD (rotational=0 in sysfs), which it may use to tune itself a bit differently. Aside from discard and noatime, I don't think there's a real need to stray from ext4 defaults.

Gabriel
  • 719
0

If you put discard in the fstab mount arguments for a filesystem on a bcache device, then the filesystem will issue TRIM commands to bcache for deleted blocks. In theory bcache could use incoming TRIM commands as hints for freeing cached data, but I don't think it does, and there are hints searching online that bcache doesn't understand incoming TRIM commands at all (I found one unverified report of errors).

However, bcache can itself send TRIM commands when it deletes buckets on its caching SSD device. By default it doesn't enable this because TRIM is not queued on pre-SATA3.1 drives so it's slower, but on modern SSDs enabling discard gives better peformance.

TLDR; don't put "discard" in /etc/fstab for a filesystem on a bcache device, but endable bcache's discard in /sys/block/*/bcache/discard if your cache device is a modern SATA3.1 SSD.

UPDATE 2023-02-28: For at least kernel 6.x.x things have changed.

For bcache the /sys/block/*/bcache/discard setting doesn't exist any more, at least for my old ssd. It might only appear for drives that support queued trim (SATA3.1) or just defaults to "on" for drives that support it. It doesn't seem to have any problem accepting TRIM operations from filesystems, but I don't know if it just ignores them or uses them as hints for discarding buckets.

For btrfs it automatically detects bcache devices as "non-rotational" so adds the ssd mount option by default. It will "discard" whole bcache devices when they are first added, but discard is not "on" by default. I suspect using the btrfs mount option discard=async would be fine; worst case bcache ignores it, best case it uses it as a hint for deleting buckets.

Another btrfs mount option that is probably worth adding is ssd_spread. From the description this turns on trying to keep data contiguous. It currently defaults to off because modern ssd's don't care, but it's probably beneficial for bcache as it will keep data more contiguous on the non-ssd backing drives.

Donovan Baarda
  • 101
0

On Kernel 6.4.11 I've managed to find discard for my WD SN750: /sys/block/nvme0n1/nvme0n1p1/bcache/discard

It is disabled by default

Francisco Boni Neto
  • 1