Does anyone here have experience with #bcache (not the bcachefs filesystem!) the #Linux kernel's block layer cache?

Apparently it allows you to use SSDs in front of HDDs for performance.

https://www.kernel.org/doc/html/latest/admin-guide/bcache.html

I'm running my own #Kubernetes cluster on bare metal at #Hetzner. I'm going through different iterations of node configurations, and trying to figure out how to squeeze the most out of a hardware configuration with a 10TB+ HDD drive and two 512GB #NVME drives. #bcache has apparently been discontinued, which leaves me with #dmcache, which is nicely built into #LVM.

One catch though: you need to create NVME cache volumes for each of the data volumes you create. This is all well and good if you're using a single volume for everything, and tools like #Longhorn work well in this kind of setup. Others, like the #OpenEBS LVM provisioner don't. There is a version in the making that just provisions raw disk images as files on whatever filesystem you have, but it's still lacking some features that are vital to me - primarily the ability to offer up StorageClasses that provision on different paths of the node, so I can pick a fast or slow filesystem to store it on.

Tips for other solutions?

Des personnes par ici ont de l'expérience avec l'utilisation combinée de #bcache et #btrfs ?
Vous auriez des retours d'expérience et conseils / recommandations ?

C'est pertinent comme cache en lecture (surtout) si on a une asymétrie du style 500Go de SSD pour >10To de HDD ?
Il me semble que pour mon cas d'usage c'est la lecture aléatoire qui est la plus pénalisante.

1/3

Собирали франкенштйена из mdadm, LVM и bcache? Теперь попробуйте ZFS

Привет! Меня зовут Ваня, я системный администратор

https://habr.com/ru/companies/selectel/articles/921770/

#selectel #zfs #mdam #lvm #bcache

Excited for Btrfs RAID1's "preferred read device" feature in Linux 6.14. This allows to have one fast device, example SSD backed bcache device and other slow cheap hard drive. We can set the bcache deice as preferred read device so reads are always fast.
It also wears down only one disk reducing the chance of both the disks evenly wearing out which increases the chances of both of them failing around the same time.

From the pull request:

> more read IO balancing strategies (experimental config), add two new
ways how to select a device for read if the profiles allow that (all RAID1*),
the current default selects the device by pid which is good on average
but less performant for single reader workloads
- select preferred device for all reads (namely for testing)
- round-robin, balance reads across devices relevant for the requested IO
range

Source: https://lore.kernel.org/lkml/cover.173[email protected]/

#btrfs #linux #linux_6_14 #filesystems #bcache #raid #raid1 #nas #selfhosting #selfhost