flash och snurr används till olika saker - de som förstår det bygger en vettig kompromiss med båda ingående.
Sedan uppvisar Flash en massa saker som tex SLC-Cache opålitlig överföringskapacitet vid stora och tunga dataflytt eller skrivning av stora filer med hög hastighet under lång tid - det är då man ser kompromisserna hårdhänt...
Det andra, väldigt oväntat och förtroende för SSD fick sig en törn för min del, på förvisso äldre MLC-SSD - TRIM-intrassling som gör SSD enormt slö, så slö att en laptop-snurrdisk kör cirklar kring den och märkvärdigt svår att få disken snabb igen (i princip krävs en secure-erase omgång eller motsvarande med zerofill hela disken flertal gånger innan farten är tillbaka igen).
Idag med dagens SSD/NVMe kanske det fungerar bättre men skall ha SSD som write-back cache mellan datorn och snurrdisk så skall man verkligen vara försiktig och testa med tunga skrivlaster med småfiler och före och sedan efter mäta skriv och läs-delayer och har de ökat märkbart efter testerna så skall man dra öron åt sig då en havererad write-back cache vill man _inte_ ha om datat på snurrdisken skall vara räddningsbar.
Min rätt säkra koncept att köra sönder en äldre MLC-SSD-disk inom ett dygn är följande:
En snurrdisk sätts upp via bcache (och sagda SSD) och sätts upp write-trough[1] med BTRFS-filsystem ovanpå som har komprimerande subvolym och man kör in diskimage med nästan samma innehåll i subvolymen så många man får rum med.
Därefter hämtar man ned 'bees' och kompilera upp den och starta upp en deduplikation av sagda snurrdisk via förstås bcache med defaultinställningar. - nästa morron kommer du förmodligen finna din SSD utsparkad av linuxkernel för att SSD slutar att svara inom tid (titta i dmesg - där ser man för att OS först tillåter längre och längre svarstid men till slut är borta så länge att SSD-disken sparkas ut) medans dedupliceringen fortsätter som innan (men lite långsammare) - bcache har en skyddmekanism där den kan göra sig av med SSD om den inte längre fungerar - dock inte i write-back mode...
Den här övningen skriver inte ut SSD-disken kapacitet på långa vägar - förmodligen inte ens en hel diskvolym i mängd utan det som verka trassla är SSD interna reallokerinstabell av sektorer och flashdatablock (~TRIM) - trasslar in sig fullständigt och hittar inte ut inom rimlig tid för varje ny skrivning/läsning. - har provat på 3 olika diskmärken (Liteon, Adata och Samsung 830) - alla havererade och blev utslängda av OS inom en natt och den som jag inte lyckas få 'säker' igen och fortfarande ger långa delayer innan SSD svarar igen ibland är Samsung 830 och förmodligen måste man göra en secure erase på den...
Det här problemet finns att läsa om äldre SSD-artiklar men verkar inte vara något man bryr sig om längre och fokus är bara antal GB flash-minne per krona och snabbhet (vid små skrivmängder) och man blundar för sådant.
Konsument SSD för cache-jobb i write-back mode för tex. snurrdiskar avråder jag det bestämdaste från då det annars kan bli en väldigt otäck överraskning med icke räddningsbar filsystem på snurrdisken... och vill man ha write-back cache - kolla noga med mycket hård last skrivning/läsning av den värsta sorten på få-sektonivå, det som 'bees' i det här fallet framkallade då på komprimerande disk med BTRFS så hanteras komprimerade filer i 32k-Bytes-block för komprimerande data och inom ramen för att bcache skulle hugga på det hela tiden med uppdateringar mot SSD-cache vare sig det läste eller skrev mot snurrdisken.
[1]
Kör du write-back cache i testet så kommer snurrdiskens filsystem att totalhaverera och du får börja från början igen om du vill testa nästa SSD...
