Frågor om NAS, ZFS och ECC

För det första så med DDR så är det en näst intill obefintlig chans att en fil inte passerar alla moduler, men ett fel behöver i och för sig inte inträffa på en hel modul utan ofta är det några bits som har fastnat (produktionsfel) eller som byter värde godtyckligt (bitflip).

Det är sant som du säger att en scrub vid det som jag beskriver som produktionsfel kan resultera i att felet i minnet smörjs ut över datat. Men detta gäller inte fel som inträffar av stålning eller liknande eftersom man då inte får den "mönstereffekten" som gör att samma del av minnet konstant uppvisar fel värden.

Det som en scrub gör är ju primärt att läsa data och därmed involvera den felaktiga komponenten i datorn i beräkningar. Eftersom det i princip är omöjligt för mjukvara att på ett effektivt sätt skydda sig från fel i RAM så kommer detta att kunna ha effekter. Men samma sak gäller i ett traditionellt filsystem. Mitt poäng var att minnesproblemen med mycket stor säkerhet kommer att upptäckas av ZFS och att det faktum att hur mycket minne som används samtidigt inte spelar så stor roll då de flesta OS försöker att maximera användandet av RAM eftersom det är flera magnituder snabbare än roterande rost.

Argument som att andra filsystem är mindre sårbara för att det har mindre fotavtyck i minnet, när de inte ens kan meddela om att de data de levererar är felaktiga är det jag reagerar på. Skit in -> Skit ut. Man mår inte bättre av att inte vet om det. När man designar system som ZFS måste man ha någon form av inflexionspunkt som allt byggs upp kring. Minnet i ett datorsystem är denna punkten, man måste lita på det i dagens datorer. Man kan kontrollera det för fel och reparera dessa, men man måste till 100% lita på minnet.

Innan ZFS rapporterar att det lagat ett fel så rapporterar det att det hittat ett fel, och ett fel betyder att du har problem med hårdvaran. Kör man utan ECC är det där man ska börja sin felsökning.

Amen för fan...
Det är helt omöjligt för någon eller något att reverse-räkna en checksumma på det sättet du beskriver. Det som kommer hända i ditt scenario är att ZFS kommer kolla ifall det finns en version av filen någonstans på disken med korrekt checksumma och om så är fallet ersätta den "korrupta" filen med en "known good" fil som har en korrekt checksumma. Om inte så kommer ZFS bara notera, dock felaktigt, att sektorn som filen låg på bråkar och markera den som dålig.

Har man kasst RAM-minne löper man risken att filer förstörs varje gång filer läses in i RAM och skrivs tillbaka till hårddisk, oavsett vilket filsystem man har. Skillnaden med ZFS/btrfs gentemot NTFS/Ext4 är att de sistnämnda aldrig märker att något är pucko.

Så, om jag har en Raidz1 med 5 diskar och en av diskarna dör, hur är det då möjligt att datat på den disken inte förloras, magi?
När jag sedan resilverar arrayen med en ny disk: var kommer datat från den gamla, trasiga disken från?

Huh? nu är det ju så att ZFS data integrity (checksumming vid läsning eller scrub) även fungerar i Raidz1/2/3. Fungerar även på en ensam disk om man specificerar copies=n>1.

Förövrigt, paritetsdata != checksums.

Nu när vi går in i såpass detalj tycker jag det är viktigt att påpeka att vi talar om block inte filer. På en mirror finns det ett syster-block till varje block, på ett raid-z1 / raid-z2 system finns det datablock för varje disk minus 1 eller 2 beroende på raidz nivå.

Checksummorna i ZFS är lagrade i ett Merkle träd (checksumman för ett block är lagrat i pekaren till blocket). Blocken sprids ut över de tillgängliga diskarna och är av variabel storlek. Om man har ett raid-z1 system med fyra diskar så blir tre logiska-datablock till tre datablock på disk + 1 paritetsblock.

Vid varje läsning av ett block kollas pariteten. Om paritetsinformationen blir ändrad pga. att den hamnade i "dålig ram" så kommer kommer checksumman inte stämma. ZFS vet inte var felet ligger utan läser de övriga blocken från de andra diskarna och kollar om dessa ger rätt checksum. Hamnar samtliga av dessa block i dålig ram så blir det omöjligt att reparera det "felaktiga" blocket. Dock försöker ZFS läsa data som ändras om igen och igen om det då stämmer så går det vidare.

Felen fortplantar sig inte via en scrub, de upptäcks och kan felaktigt rättas pga. fel i ram. Om det uppkommer nya fel så är det för att det sker fler fel i ram, inte för att ZFS felaktigt rättade tidigare. Scrub lämnar alltid det den jobbat på 100% intakt. Felen fortplantar sig inte genom scrub, de kommer alla från felaktig ram.

Risken finns at man använder skadad paritet för att reparera ett fel, men risken är också låg att man får fel på en hel stripe av block och således förlorar data. Det gäller inte som du påstår ovan att ZFS plötsligt rättar till det felaktiga blocket, med dålig data och man får en kaskadeffekt över hela poolen.

Med en enkel

zpool status -v

kan man till och med se vilka filer som hade block som ZFS inte kunde läsa (mer data än du hade redundans för förstördes av ram).

Nej, du kan Det handlar inte om filer utan block. Tre av fyra diskar i raid-z1 räcker för att ge alla filer tillbaka. (Den fjärde disken var den som hade en ckecksum som hamnade i i dålig ram.)

Jo, en tvåvägsmirror och Raid-z1 klarar ett fel. Raid-z2 klarar två fel osv. Grejen med minnesfel av den typen vi diskuterar är att de uppenbarar sig som diskfel som egentligen inte existerar. För att ZFS inte ska kunna returnera data så måste samma block på samtliga diskar hamna på ett ställe i ram som har en bit satt till ett värde som inte motsvaras av datat.

Om man har kör utan ECC och har errors under en scrub borde man alltid undersöka RAM först. Det är knappas kosmisk strålning som orsakar många flippade bits utan hårdvarufel.

Att ZFS på en enda disk utan några kopior av data fortfarande kan läsa filsystemet efter att upp till 1/8 av disken är överskriven är bara det en god anledning att köra ZFS. Visst, man kan ha förlorat data, men metadatablocken är såpass utspridda på disken att man fortfarande kan traversera filsystemet och få indikation på vilka filer som inte går att läsa. En 4TB disk med NTFS är en tidsbomb, ni tror väl inte att ReFS utvecklades bara för at det var kul?

Jag föredrar att få en indikation på att data kan vara utsatt i motsättning till att inte veta om det.

Högre datatäthet och prispress gör att man tillåter mer fel på disken som man senare korrigerar i firmware. Det är därför det sitter "stora" ARM kontrollers på dagens diskar. Situationen är inte så galen som SSDs, men den börjar närma sig.

På den aktuella WD40EFRX anger WD att det blir bitfel maximalt 1 på 10^14, vilket betyder maximalt ett fel per 12.5 TB. Då om du har otur kommer du få ett fel innan du fyllt disken fyra gånger.

Tidsbomben ligger i det faktum att man inte har koll på hur data mår innan man läst det och då är det redan för sent.

Kör man raid är det värre eftersom hastigheten på diskarna inte har ökat så mycket som kapaciteten. Du har ett raid5 system med fyra diskar som i exemplet ovan och en disk går sönder. Du är mycket snabb och byter genast ut den felande disken med en ny. Under optimala förhållanden tar det ca 7:30 att återskapa ditt raid till den nya tomma disken (150 MB/s i skrivning i snitt). Under denna tiden är de andra gamla diskarna under maximal stress och måste läsa 3*4TB på tre spindlar = 12 TB data läses, varje spindel ger i värsta fall genomsnittligt 12.5 TB data innan ett fel, du kommer statistiskt att få 12TB / 4,17 ≈ 3 Bit fel under rekonstruktionen. (Om en spindel ger ett fel per 12,5TB så ger tre spindlar ett fel per 4.17TB).

För att inte tala om den ökade risken att du löper att ännu en av diskarna ger sig likt den första under tiden du återbygger. De har ju trots allt samma historik, varit utsatta för samma load och miljö sedan driftsättningen.

Man får samma problem med raid-z1 som raid5, med några undantag: Enstaka bitfel kommer inte att förstöra filsystemet eller göra delar av det otillgängligt. ZFS återskapar bara de data som behöver återskapas, på ett 4*4TB enkelparitet fyllt till 75% behöver ZFS återskapa 3TB medans MDraid och HW raid måste återskapa 4TB. Annars är det stort sett lika.

Ja Raid-Z2 är att föredra vid flera diskar. Vid 4 diskar så kan man ju köra stripade mirrors (RAID-10).

Jag håller med, läste just genom End-to-end Data Integrity for File Systems: A ZFS Case Study:

Som jag ser det är det bättre att veta när man inte kan lita på ett dataset, byta ut den felaktiga komponenten och jämföra med backup än att leva i tron om att allt är "fine and dandy" och inte veta något om problemen som din server upplever. Oavsett om man har ECC eller ej.

Därför skulle jag välja ZFS framför andra filsystem alla dagar i veckan. Jag uppskattar den enorma utveckling som ligger bakom ZFS och förstår vilka utmaningar som utvecklarna på SUN stod framför när de skapade filsystemet.

För några dagar sedan postade jag lite länkar för den som är intresserad att höra utvecklarna själva berätta lite om hur systemet är designat och utvecklat:
FreeBSD: Utöka ZFS mirror pool#8

Post Mortem: Seagate ST3000DM001 Som kuriosa kan jag nu meddela att jag hade mitt första diskhaveri nu här om dagen. Jag kör ett raidz2 array med 6 stycken Seagate 3TB. Alla med uppgraderas firmware CC4H för att de inte ska hålla på och låsa huvudet stup i kvarten.

Den felande disken har under en tid visat tendenser på att inte hänga med, SMART data visar att den mappar om sektorer under hårt arbete med skrivning till tidigare oanvänt område. Under förra scrub så gick den det mycket sakta och SMART visade att antalet felaktiga sektorer ökade. Jag höll ett öga på zpool status för att se när felen skulle visa sig för ZFS. Efter några timmar så började det dyka upp några fel, först 128 kB, sedan 512 kB och efter ytterligare en stund blev det ont om lediga sektorer att mappa om till och disken tvärdog. Då hade scrubben segat iväg på ett fåtal MB/s en stund.

Efter att ha bytt ut disken så tog det nästan 9 timmar att återställa 1.93TB till en ny disk, så resilverprocessen har snittat ca 61 MB/s. Det är här man är glad över två saker: 1. Att ZFS inte behöver återställa mer än vad som är använt (i mitt fall 2/3 av diskarna). 2. Att man inte har färre, större diskar som är fyllda ännu mer. IO hos varje disk är en klart begränsande faktor vid resilvering. Dock ska det märkas att hastigheten varierar mycket under resilverprocessen, det är endast om man låter "zpool iostat tank 60" integrera över minst en minut som man får en rättvis hasighetsindikation pga. den mycket godtyckliga strykturen på data hos ZFS.

Mitt array är nu uppe och rullar igen. Förlorade ingen data och har skickat förfrågan om RMA på disken som endast är två år gammal; snurrat 1,4 år; startat ca 40 gånger; parkerat huvudet ca 10000 gånger och haft en maxtemp på 40 grader (snitt temp är 33, men varma sommardagar kan ställa till det om det kommer en del IO).

Jag brukar hålla koll på SMART eftersom diskarna kan rapportera temperatur via detta interface, även om installationen är virtualiserad (systemets temperatur måste jag kolla i ESXi). Har några script för att plocka ut "oegentligheter" som jag hämtat från Zfsguru projektet som jag gillar även om utvecklarna brukar vara väl optimistiska i sina tidsestimat och senaste orsak till försening var att de bygger ett helt eget (!!) CMS för systemet.

Jag fick en varning att en disk betedde sig underligt under en scrub, många sektorer rapporterades som remappade för att disken sedan framstod som om den var utan problem. Eftersom jag inte kan "polla" SMART konturneligt så var det ju bara tur att scriptet hann se det. Men att ha ett öga på SMART tror jag är smart.

Har du lust att dela med dig av scripten ? Jag vill försöka få till någon SMART övervakning på min N54L som kör Synology DSM porten XPenology med RDM mappade diskar.

Kan kan packa i hop de lite senare när jag har tid, det är verkligen inget fancy och bara parsar rå output från smartctl.

Intressant, såg detta script också:
https://calomel.org/zfs_health_check_script.html

Vilken större omfattning kör smartctl? Kör du long eller short test? Testar ett long test på en av mina diskar nu för att se vad jag får för output.

Det är inte testen som jag kör, utan bara utläsning av SMART data. Ska packa i hop filerna nu, men garanterar inte att de kommer att köra på andra system. Jag är verkligen inte sugen på att maintaina något nytt projekt just nu.