De jag har provat är LITEONIT LCS-128M6S, ADATA SP900 64 GB, Sandisk X300s 128GB (skräpdiskar jag hade liggande och inte gråter om de blir utslitna) och sist Samsung 830 256GB som aldrig har blivit sig riktigt lik efter detta (och i 830:s fall det finns bekymmersamma poster "SATA Phy Event Counters (GP Log 0x11)" med höga uppräkningar i antal event (jag menar inte 10-tal event - jag menar 5-siffrigt i antal...) om man tittar i slutet av dataflödet när man kikar med smartctrl -x (som ger mer och vendorspecifik information som normalt inte syns i standard SMART) med misslyckade kommandon, com-reset etc.
Alla utom möjligen Sandisk X300s är av MLC-typ och ingen av dem klarade sig särskilt väl. sandisk och liteon hängde sig så hårt efter ett tag att de blev utkickade och bcache körde plötsligt utan SSD aktivt (i writethrough-mode), Adata gick bara fruktansvärd långsamt med typ 2 MB/s i skrivtest sedan och så Samsung 830 - som jag förväntade mig mer på, har aldrig riktigt återhämtat sig efter totalhängning trots skrivning med '0' hela disken, blkdiscard och håller på med bussblockeringar och skit även efteråt i 'vanlig' filsystem-användning...
Obs detta var inget som syntes vid 'normal användning' utan först vid när jag började deduplicera BTRFS-filsystem med 'bees' som tortyr-test. Och det jag började med först var en präktig filsystemhaveri efter ca 1 dygn när jag körde "writeback", med writethrough fungerar det hyfsat men fick finna sig i att SSD:erna var utkickade plötsligt och utan förvarning inom 1 dygn med deduplicering igång - testet gjordes mot en 2TB WD-green-disk som backend då jag tänkte att SSD-cache skulle hjälpa upp den till närmast frusna sirapen långsamma söktiden (> 20 ms) på dessa diskar...
- Med Bcache i Writeback-mode som syndare var för mig den första BTRFS-filsystemet som inte gick att reparera eller rädda filer ur efter haveri och efter analys förstod jag varför - metadata för filsystemet hade i princip inte lämnat SSD:n som kraschade (och ej kunde identifieras efteråt av bcache-systemet) då default så görs det inte någon intervallbaserad synkning alls av data mellan SSD och bakomliggande snurrdisken i bcache.
Writeback är det som är det mest attraktiva med SSD-cache när man jagar prestandaökning - men här visade sig också vara den farligaste tillämpningen den dagen när det skiter sig i SSD:n och man förlorar precis allt!!
Man såg under körning med 'bees' med dmesg att svartiderna från SSD blev hela tiden långsammare och långsammare, börjar med busreset och till sist kickade ut för att det inte svarade alls inom ganska lång tid (> 8 sekunder) - ungefär i beteende som en SMR-disk som fått sin PMR-del knökfull av icke sammanhängande sektorer som den aldrig får tid för att städa ur... och jag skulle tro att det är samma sak med en TRIM-tabell i SSD som blivit fullständig spagetti av kedjereferenser till varandra och GC hinner aldrig reda ut dessa igen för att få 8-64 MB frigjorda och raderbara block i flashen då det fylls på mer än det hinner tömma.
Det jag skall prova med på Samsung 830 är att göra en security erase och se om den blir människa igen - då nollställs alla trimtabeller etc. olika logiska nystan och börja på samma nivå som ny direkt ur förpackningen. Dock är det en smula bökigt då det måste går via SATA och man skall bränna specifik USB-bootsticka för jobbet om man gör det via samsungs magican ... (det går också via hdparm också, men där måste man fan hålla tungan rätt i munnen för att inte riskera en permanentlåst-disk då ATA-password är involverat)
---
bcache skall inte bry sig om vad som hanteras ovanpå imagen med filsystemet mer än att det cachar när läs och skrivstorlekar av sektorföljder är under en viss (och ställbar) nivå mot disken eller läser från disken då man avsiktligt inte cachar stora sekventiella skrivningar/läsningar då hastighetsvinsten är liten och skulle ge stor slitage på SSD - och med moderna SSD med SLC-cache i begränsad storlek för TLC och QLC-SSD/NVMe så finns risken att de blir fullskrivna fort vid stora filskrivningar/läsningar och då blir SSD väldigt långsamma, långsammare än snurrdiskar...
---
Om jag skall vara ärlig så blev jag lite besviken på bcache och framförallt hur illa SSD klarade sig i situationer där de borde excellera i prestanda men i själva verket havererade istället (och med katastrof i vissa cache-moder) vid tung kontinuerlig last som aldrig släpper i dygns perioder. Och också hur farligt det kan vara med risk för förlorade filsystem vid tunga läs och skrivlaster med writeback som scrub, resynkningar av diskar i RAID och mycket uppenbart - deduplikation på 4k-block och sektornivå då det kan hålla på i många dygn i rad utan uppehåll.
Det är samma effekter som SMR-diskar i samband med resynkning av RAID - vilotiderna som man räknar med finns för 'housekeeping' internt så att det kan tömma PMR-delen på disken, inträffar inte och för vissa RAID-system som ZFS blir en katastrof när diskar blir utkickade som knatterband efter en ganska bestämd tid när diskarna inte längre svarar inom 8 sekunder.
samma effekter tycker jag mig se efter övningen med bcache - även finns i SSD-diskar för diskaktiviteter med småsektorskrivningar som aldrig slutar utan bara håller på timme efter timme...
