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.