bcache vs dm-cache: Linux SSD Caching vergeleken
11 min lezen - 28 mei 2026

Vergelijk bcache en dm-cache voor SSD caching op Linux. Setup, prestaties, cachingmodi en wanneer ze te gebruiken.
bcache versus dm-cache: SSD-caching op Linux
SSD's zijn snel, maar duur per gigabyte. HDD's zijn goedkoop, maar traag. Linux biedt twee tools op kernelniveau om ze te combineren: bcache en dm-cache. Beide gebruiken een SSD als transparante cache voor een grotere HDD, maar ze verschillen in architectuur, installatievereisten en waar ze het beste presteren.
Hoe bcache werkt
Bcache is sinds versie 3.10 (juni 2013) in de Linux-kernel opgenomen. Het werkt op de bloklaag, dus het werkt met elk bestandssysteem dat UUID's ondersteunt.
Intern maakt bcache gebruik van een hybride B+-boom/log-structuur. Het verdeelt SSD-opslag in buckets van vaste grootte (128K tot 2MB), uitgelijnd op de grenzen van wisblokken. Dit zet willekeurige schrijfbewerkingen om in sequentiële, wat de schrijfversterking vermindert en de levensduur van de SSD verlengt. Sequentiële I/O-bewerkingen van meer dan 4MB omzeilen automatisch de cache, waardoor de SSD zich kan concentreren op de willekeurige toegangspatronen waar deze de meeste waarde toevoegt.
Bcache bewaakt ook de SSD-latentie in realtime. Als de leeslatentie 2 ms overschrijdt of de schrijflatentie 20 ms, wordt het verkeer afgeremd om te voorkomen dat het cacheapparaat een bottleneck wordt.
Installatie
Installeer bcache-toolsen formatteer vervolgens uw back-upapparaat en cacheapparaat:
make-bcache -B /dev/sdb # format HDD as backing device
make-bcache -C /dev/sdc # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach # attach cacheTuning tijdens de uitvoering gebeurt via de /sys/block/bcache<N>/bcache/ sysfs-interface, waar u cachingmodi, drempels voor sequentiële I/O en latentiedoelstellingen kunt aanpassen. Gebruik voor RAID-arrays --data-offset om af te stemmen op uw stripe-breedte.
Het addertje onder het gras: de installatie is destructief. Beide apparaten moeten worden geformatteerd als bcache-doelen, dus u kunt bcache niet toevoegen aan een bestaand bestandssysteem zonder dit eerst te wissen. Bcache-apparaten kunnen na het aanmaken ook niet meer in grootte worden aangepast.
Prestaties
De schrijfconsolidatie van Bcache zorgt voor sterke willekeurige schrijfcijfers. In benchmarks heeft het ongeveer 18.500 willekeurige 4K schrijf-IOPS bereikt, vergeleken met 12.200 IOPS op de onbewerkte SSD alleen. De willekeurige leessnelheid kan ongeveer 1.000.000 IOPS bereiken met geschikte hardware.
Voor versleutelde workloads kunt u dm-crypt bovenop het /dev/bcache<N> apparaat in plaats van de onderliggende schijven afzonderlijk te versleutelen. Dit levert doorgaans betere prestaties op omdat bcache schrijfbewerkingen nog steeds kan consolideren vóór de versleuteling.
Hoe dm-cache werkt
dm-cache is een Device Mapper-doel dat bovenop een bestaand logisch volume zit. Het maakt gebruik van drie subapparaten: een bronapparaat (HDD), een cacheapparaat (SSD of NVMe) en een metadata-apparaat dat bloklocaties en dirty-statussen bijhoudt. Het standaard cachebeleid is smq (Stochastic Multi-Queue), dat hot data identificeert in gemengde workloads.
Het belangrijkste voordeel: dm-cache kan op een live LVM-volume worden gelegd zonder bestaande gegevens te vernietigen. U kunt het formaat ook aanpassen met standaard LVM-opdrachten.
Instelling met LVM
De praktische manier om dm-cache te configureren is via lvmcache. Handmatige dmsetup configuratie is mogelijk, maar foutgevoelig en gaat niet mee bij het opnieuw opstarten. De LVM-aanpak:
- Maak fysieke volumes (PV's) aan op zowel de HDD als de SSD.
- Voeg beide PV's toe aan één volumegroep (VG).
- Maak drie logische volumes aan: één voor back-upgegevens (HDD), één voor de cache (SSD) en één voor metadata (SSD).
- Combineer de cache- en metagegevens-LV's tot een cachepool:
lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv> - Koppel de pool aan de bron:
lvconvert --type cache --cachepool <pool_lv> <data_lv>
Een ding om op te letten: koppel het bestandssysteem via het /dev/mapper/ pad, niet via de UUID. Koppelen via de UUID kan de cachelaag omzeilen en het bronapparaat direct raken.
Prestaties en geheugen
In de writeback-modus bij een 90/10 lees/schrijf Zipf-workload heeft dm-cache leessnelheden van ongeveer 193 MB/s en schrijfsnelheden van ongeveer 21 MB/s behaald. In een andere benchmark verhoogde het cachen van een 100 GB HDD met een 10 GB NVMe-partitie de willekeurige schrijf-IOPS van 118 naar 798.
De afweging is het geheugen. De metadata-overhead van dm-cache is afhankelijk van de blokgrootte. Een blokgrootte van 512 bytes kan meer dan 16 GB RAM per 100 GB cache verbruiken. Door dat te verhogen naar 4.096 bytes daalt het geheugengebruik tot ongeveer 2 GB per 100 GB. Kies een blokgrootte die dicht bij uw gemiddelde I/O-grootte ligt (64 KB is een redelijk uitgangspunt) en zorg ervoor dat deze een veelvoud is van 64 sectoren (32 KB), binnen het bereik van 32 KB tot 1 GB.
Metadata wordt bij elke FLUSH- of FUA-schrijfbewerking, of ten minste één keer per seconde, doorgeschreven. Voor hoge beschikbaarheid moet u het metadata-apparaat spiegelen om een single point of failure te voorkomen.
Cachingmodi
Zowel bcache als dm-cache ondersteunen dezelfde kerncachingmodi. De keuze heeft invloed op zowel de prestaties als de gegevensveiligheid.
| Modus | Hoe het werkt | Snelheid | Risico |
|---|---|---|---|
| Doorschrijven | Schrijfbewerkingen gaan tegelijkertijd naar zowel de SSD als de HDD | Alleen leesversnelling | Laag. HDD bevat altijd de actuele gegevens. |
| Terugschrijven | Schrijfbewerkingen gaan eerst naar de SSD en worden later naar de HDD doorgeschreven | Lees- en schrijfversnelling | Hoger. Als de SSD uitvalt vóór het doorschrijven, leidt dit tot gegevensverlies. |
| Omzeilen / Doorsturen | Schrijfbewerkingen omzeilen de cache volledig | Alleen leesversnelling, minder slijtage van de SSD | Laag. HDD heeft altijd actuele gegevens. |
Writethrough is de veilige standaardinstelling voor beide tools. Writeback is sneller, maar brengt een reëel risico met zich mee: als de SSD uitvalt terwijl er nog niet-doorgeschreven gegevens op staan, zijn die gegevens verloren en kan het bestandssysteem beschadigd raken. Gebruik writeback alleen als u over redundante SSD's beschikt of incidenteel gegevensverlies kunt tolereren.
bcache versus dm-cache: welke moet je gebruiken
| Factor | bcache | dm-cache |
|---|---|---|
| Instelling op bestaande gegevens | Destructief (vereist wissen) | Niet-destructief (online conversie) |
| Formaat wijzigen | Niet ondersteund | Ondersteund via LVM |
| Optimalisatie van willekeurig schrijven | Sterk (consolidatie van sequentieel schrijven) | Standaard |
| Sequentiële I/O-bypass | Automatisch (>4 MB) | Beheerd door smq-beleid |
| Geheugenoverhead | Laag (B+-boom) | Hoger (afhankelijk van blokgrootte) |
| Metadata | Op cache-apparaat | Apart apparaat, kan worden gespiegeld |
Gebruik bcache wanneer u een nieuw systeem vanaf nul opbouwt en de best mogelijke willekeurige I/O-prestaties wilt. Het is de betere keuze voor schrijfintensieve workloads zoals databases en VM-opslag, en voor RAID 6-arrays waar de nadelen van willekeurig schrijven groot zijn.
Gebruik dm-cache wanneer u caching moet toevoegen aan een server die al in productie is. Dankzij de LVM-integratie kunt u een cache koppelen zonder downtime of gegevensmigratie. Het is beter geschikt voor leesintensieve workloads en omgevingen waar u de flexibiliteit nodig hebt om de opslaggrootte direct aan te passen of opnieuw te configureren.
Conclusie
Beide tools lossen hetzelfde probleem op, maar zijn geschikt voor verschillende situaties. Bcache is de beste keuze qua prestaties voor nieuwe installaties. dm-cache is de praktische keuze voor bestaande LVM-systemen. Welke u ook kiest, begin met de writethrough-modus totdat u zeker bent van de betrouwbaarheid van uw SSD, en schakel vervolgens over naar writeback als u de schrijfprestaties nodig hebt.
Als u dedicated servers met SSD-cachingconfiguraties nodig hebt, bekijk dan de dedicated serveropties van FDC.
XDP en eBPF voor Linux pakketverwerking
Hoe XDP en eBPF miljoenen pakketten per seconde verwerken op het niveau van de NIC-driver. Benchmarks, DDoS use cases, toolchain setup en hardware vereisten.
14 min lezen - 27 mei 2026
Waarom het belangrijk is om een krachtige en unmetered VPS te hebben
3 min lezen - 9 mei 2025

Hebt u vragen of wilt u een oplossing op maat?
Flexibele opties
Wereldwijd bereik
Directe inzet
Flexibele opties
Wereldwijd bereik
Directe inzet