Bcache jobbar inte som du tror - den kollektar bara småskrivningar där söktiden skulle bli dominerande gentemot transfern av datan medans stora filer (typ över 4 MB - det går att ställa in) går rakt igenom och då lagras med disken hastighet.
Test med 'disk' i ubuntu ger helt fel resultat då det är stora sekvensiella block som skrivs, likaså många andra disktestprogram. - sedan att det bara går med 30 MB/s tyder på andra problem också med dina bakomliggande diskar
En sak till med Write-back - är din SSD mogen för det, jag menar verkligen mogen för det och inte får trimtabelltrassel med allt komplexare allokeringar så att disken svarar långsammare och långsammare för att till slut sparkas ut av kärnan ?? - ha inga viktiga filer som inte har backup när du använder denna mode - lägger den SSD:n av så kan du säga adjöss till din filsystem och då menar jag att den är trasig ordentligt på riktigt. Kör du writethrough och writearound så är skrivningarna i alla fall datasäker när SSD:n ger upp.
Det är nämligen så att Bcache synkar inte datat mot surrdiskarna regelbundet defaultmässigt och tex metadata för filsystemet som hela tiden ändras i små block åker aldrig ut på snurrdisken utan stannar kvar bara i SSD-cachen.
Vill du verkligen plåga SSD för att se att den håller så lägger du en BTRFS ovanpå din Bcache - skapar en subvolym som är komprimerande (skrivna och lästa sektorer är då i 128 kB-block för komprimerad data) - fyller volymen med diskavbilder med små ändringar mellan avbilderna - i nödfall kan det vara samma avbilder.
Sedan kompilerar du upp dedupliceringsprogrammet 'bees' och kör igång den på bcache-volymens BTRFS-filsystem och då lämpligtvis bcache i writethrough - du har volymen kvar efteråt när OS har sparkat ut SSD för att den inte längre svarar i OS inom tid (du följer det i 'dmesg' där det först börja meddela att SSD-enheterna har längre svarstid och till slut sparkas ut av kärnan typ tidigt på morronen) av den tunga skrivlasten och testet brukar inte överleva natten (har provat på 3 SSD, liteon, Adata och samsung 830 - ingen överlevde natten och samsungen är fortfarande konstig trots zeroing och verkar vara brickad).
När man analyzerar SSD som har hängt sig i Bcache användning så är samtliga 3 SSD symtom att det går skitlångsamt när man skriver sekventiellt med slumpad data från disken sektor 0 och vidare och somliga stannar helt efter ett tag och det går inte att skriva till slut utan en power reset/omstart. zeroing (skriva disken med '0' från början till slut) brukar kunna genomföras helt igenom men skrivfarten är bedrövlig även här med SSD-diskar mått (typ 50 MB/s när man förväntar sig +250 MB/s) tills man kört 'zero' ett par vändor och SSD:n börjar närma sig sina datablads-hastigheter)
När man sett detta så skulle jag _aldrig_ spara viktig data genom SSD-cache mot backend-diskar och det är i läge Writeback för SSD-cachen, utan nöja sig med writethrough även om prestanda är betydligt sämre (dvs. disken meddelar 'OK' först när datat är skrivet fysiskt av den fysiska disken - medans vid writeback så är det SSD:n som ger kvitto fast datat inte garanterat nått den fysiska disken (och i bcache kan data bli kvar i SSD väldigt länge innan det trängs ut på fysisk disk pga. att den inte accessats på lång tid och plats behövs))
Skall man ha writecache aktivt på en RAID så pratar vi om de dyra, professionella SSD typ 10-dubbla priset gentemot en konsument-SSD - och det först efter omfattande småsektorskrivtester med bcache som tex 'bees' gör enligt ovan (dvs kan köra i många dagar med dedupliceringsuppdrag med bees och hela tiden ladda in nya diskimages på filsystemet allt eftersom de som finns smälter ned till nästan inget alls i diskförbrukning, utan att SSD visar tecken på längre svarstider)
Problemen för mig har inte varit bcache när det havererar - utan på SSD och dess trimtabell-hantering inte håller måttet med väldigt många små block som skrivs - och skall jag vara ärlig så har tilltron på SSD/NVMe fått sig en törn vid användning utanför 'konsument bruk'
Och man skall komma ihåg att SSD/NVMe-Cache i en NAS/server så är det inte 'konsumentanvändning' längre i skrivmönster och då kan bubblan spricka om det är för enkla/billiga SSD/NVMe som används - be då att det inte är satt som 'writeback' den dagen när det händer!!
