vet inte exakta detaljer
Det var backup men också arkiv - och att problemet var lika på flera setup med multipla drivers med samma typ av ZFS-pool med samma krångel att man inte fick upp alla diskar i poolen hur han än försökte med olika startordningar - nu var han förnuftig nog att inte göra något förhastat och rådfråga hos ZFS-gurus först om det är ZFS-haveri på gång och blivit lite guru själv på kuppen efter händelsen. Dock har han uppenbarligen tappat förtroende för ZFS på externa USB-diskar efter detta och nu kör BTRFS enkom på externa USB-diskar och plötsligt börja talar väl om BTRFS också till skillnad från flera år sedan då det var tummen ned och man skulle satsa på 'riktig' filsystem (ZFS) enligt kamraten - men det skall erkännas att BTRFS är i betydligt bättre skick i dag än för 4-5 år sedan när jag hoppade på det, men jag har alltid räknat med strul sker och inte blankt förlitat sig på en 'perfekt' filsystem - och jag provade mycket innan BTRFS fick förtroendet att lagra min data - och alltid i 2 upplagor på olika medier.
Så för ZFS - inga SMR-diskar, inga avstängningar av spindlar och sleep-läge när det inte är datartrafik, och att det är server/NAS-diskar med garanterat respons inom 8 sekunder och inte är generiska/konsumentdiskar (vilket i stort sett utesluter all användning av externa USB-diskar för ZFS om lagringen skall vara tillförlitlig).
Därav kan man inte säga att det är 'bara' att använda ZFS som filsystem på allt som lagrar data till vem som helst - för att den skall fungera bra så måste förutsättningarna också vara bra och det är inga fingrar mellan som tar smällen när det krånglar.
---
För BTRFS så hade jag en testsituation det bara inte gick att rädda ut några filer från BTRFS-filsystemet efteråt och det var i samband med bcache och backendsnurrdisk och skrivning i writeback-mode.
En del SSD firmware pallar inte för det i längden då dess trimtabell med reallokeringar snurrar ihop sig och kapsejsar med längre och längre responstid (troligen någon grad av exponentiell ökning då det går fort i slutet) på SSD men kan ta lång tid innan det inträffar med normal användning. - problemet är den totala katastrofen för filsystemet som blir följden när det väl händer...
Med användning av sidokanals-deduplicerare på 4k-sektornivå som 'bees' för BTRFS som kör deduplicering genom bcache så får man problemet inom ett dygn, oftast över natten om man startar det innan man lägger sig och då beroende på att responstiden till slut är så lång för SSD att Linux-OS kickar ut SSD:n ur systemet - vilket inträffar först när disken inte svarar inom flera minuter - lite varning ser man i dmesg innan med att det antal gånger ändrar tidkonstanten för diskens kommunikation och sedan klaga mer och börja med bus-reset allt mer ofta och sedan kickas SSD-disken
Då gick det inte att rädda någon data med BTRFS egna extrakt-verktyg och efter lite analys insåg jag att det i stor sett inte fanns någon metadata alls skriven på disken utan allt satt fast i den havererade SSD (som blev 'blank slate' att inte bcache heller kunde identifiera den eller återansluta och forcera en synkning i försök att få ut metadatat till snurrdisken och därmed rädda filsystemet) då default så flushar inte bcache mot disken förrän den börja bli väldigt full och då bara i småbitar i 4k-block efter block beroende på ålder och accesstäthet mm. - ingen periodisk synkning alltså då man förlitar sig på att SSD är pålitlig och är en del av disken sas. - nu finns det tusen kranar att justera i bcache så det går att få till periodisk flush/synkning om man vill - men det är inte default påslaget!
Även om man kör write-through i bcache så får man problemet nära lika snabb som writeback (typ under natten) men du räddar diskens filsystem och fungerar som en vanlig snurrdisk när SDD blivit utkickad av OS - dock är lite av syftet med SSD-cache borta när man inte längre kör writeback...
SSD:n (provat 3 olika märken - alla MLC-diskar, adata, liteon och samsung 830) och därmed ganska gamla och därför som jag tänkte få dem 'användbara' till något) var så tröga att skriva med slumpmässig data (för att inte vara komprimeringsbar data och forcera omskrivning av flash i SSD) att de hängde sig efter ett tag efter några tiotal GB och hastigheten låg i områden 10-tal MB/s i början till att tvärstoppa och ordagrant hängde sig...
Skrev man bara '0' med 'dd' så gick det bättre och man kom igenom hela disken utan hängning men fortfarande mycket långsamt i 2-siffiga antal MB/s och känns som en exponentiell förlopp inblandat bakom när det gäller diskens interna reallokering - förmodligen sökningen i trimtabellen som inte skalar väl när det börja spreta i alla riktningar - den disken som inte repade sig helt trots fler fulla 0-skrivningar och också med slumpvärden disken igenom och dummade sig med korta hängningar och andra microstopp var Samsung 830, den blev inte som innan igen förrän man hade gjort en security erase...
Senare på hemsidan hos 'bees' har det kommit upp not att bees inte fungerade så väl med just 'bcache' och att det berodde på olika SSD:s firmware om det blev ett problem eller inte.
Lärdomen - prova mycket och väl innan skarp användning - misshandla duktigt med skrivningar med olika stora blockstorlekar - kopiera över fulla hårddiskar med backupper, småfiler, stora mediafiler etc. och kör det tills stopp (ehum... ZFS kan bli väldigt slö om man kör det stumfull och det går ibland inte tillbaka även om man tömmer disken igen - en parameter att kolla och kryssa av i utvärdering - på samma sätt som att i NTFS inte krymper sin metadata igen efter 10-miljoner filtestet och helt plösligt har 11 GB död utrymme på disken som inte går att använda till något annat än just hålla tio miljoner väldigt små filer (< 300 - 400 byte styck) eller att ext4 på 80 GB-partition inte klarar 10 miljoner filer för att dess inoder tar slut långt innan dess
- i kamratens fall var problemen som han dök på inget som märktes till en början utan kom med tiden och användningen och kanske olika OS-generationer (under flera år)... därav att det var obehagligt när det väl inträffade, dock var mycket lagrat på molnet så det var ingen katastrof men oroande att detta kunde ske på något som räknas som långtids-arkiv/backup och därav användningen av redundant flerdisk diskpool...
