ZFS på nas

Du måste såklart inte köra ECC men mycket av poängen med ZFS fabulösa dataskydd går förlorad om du inte gör det. Att skrubba hjälper inte mot fel som smyger sig in via minnet.

Du behöver heller inte någon enterprise-hårdvara. AMD har stöd för ECC tom i sina allra billigaste processorer och moderkort och ECC-minne är inte mycket dyrare än vanligt minne så 4GB+ borde inte kosta skjortan.

Det jag kör för min filserver, som väcks via WOL varje gång jag startar någon av datorerna hemma och stänger av sig själv när den inte haft något att göra på ett par timmar, är som följer:

6x 2TB Samsung Ecogreen F4EG (raidz2)
2x Kingston ValueRAM - 2 GB - DDR3 ECC
LyCOM PE-103 - kontrollerkort - SATA-300 - PCI Express x1 (för systemdisken)
AMD Athlon II X2 240e / 2.8 GHz processor
ASUS M5A78L-M LE - moderkort - micro ATX - Socket AM3+ - AMD 760G

Sen den byggdes 2011 har en disk gått sönder, reklamerats och bytts ut utan incident. Annars har allt rullat perfekt.
Borde kanske köpt mer minne eftersom moderkortets grafikkrets äter lite, men har inte märkt några problem av det, så meh.

Nej jag kör bara ZFS, i FreeBSD 10. med ECC-minnen. Och jag tror definitivt att det är en bra idé.

Utöver mirror kan du i ZFS välja raidz-1, raidz-2 osv. vilket i praktiken betyder att en respektive två diskar kan gå sönder utan att du förlorar någon data. Motsvarar raid5 och raid6 i en vanlig raidkontroller.

ZFS med Raidz1/2 kräver väl 16GB+ eccRAM om det skall lira bra?

Möjligt, men det beror nog på vilka prestandakrav man har. Det mest krävande jag gör är att redigera RAW-filer som ligger på NASen och att streama film, för det duger mina knappa 4GB tydligen utmärkt. Men det har också förbättrats avsevärt sedan FreeBSD 7 som jag började med, då kunde framförallt stora skrivningar sega ner sig rejält.

Nej, snarare tvärtom. Står du ut med att tappa halva utrymmet så är mirror det bättre valet. Det går att spegla över 3 eller fler diskar också om man är riktigt nojjig över att de ska gå sönder.

Ptja, ZFS fungerar inte riktigt som ett vanligt filsystem. Eftersom det är ett blocksystem kan du inte skapa traditionella partitioner. Dock rekommenderas det att du håller minst 20% av utrymmet på RAIDZ-arrayen ledigt eftersom det kan bli massa overhead av bland annat checksumsloggningen.

1GB RAM per 1TB lagring gäller mest om man kör dedup då den ska hålla stora dedup-tabeller i minnet. Kör du utan dedup så klarar du dig med mindre.

Jag skulle säga tvärtom. ZFS är bättre än NTFS eller FAT oavsett om man använder ECC RAM eller inte. Det blir väl inte osäkrare bara för att man får möjlighet att se om data blir korrupt? Med NTFS eller FAT och icke-ECC får man kanske samma fel i filerna men det syns inte. Därmed inte sagt att jag rekommenderar att man ska köra utan ECC, bara att ZFS är säkrare än NTFS eller FAT alla dagar i veckan oavsett ECC-mine eller ej. Behovet av ECC med ZFS är något överdrivet anser jag.

Becoming a ZFS Ninja: 1½ timme med information som kommer ändra ditt sätt att se på ZFS.
http://www.youtube.com/watch?v=3-KesLwobps
http://www.youtube.com/watch?v=jDLJJ2-ZTq8

Kanske är det så men då sannolikheten för bitfel i RAM-minnet är ganska liten så föredrar jag att filsystemet repareras än att det får fortsätta vara korrupt bara för att man är rädd för ytterligare bitfel precis då det repareras. Men som sagt var använd gärna ECC för att minska risken för datakorruption oavsett om du kör ZFS eller något annat filsystem.

Kör man med regelbundna backuper och regelbundna snapshots så känns det som man ändå är ganska säker på att kunna återställa trasiga filer.

Får du enstaka bitfel i en multimediafil (mp3, video) så kommer du inte märka det eftersom spelaren accepterar det. Får du bitfel i en binärfil tex. exe-fil, en OS-komponent, drivrutin etc. kan det sluta med en krasch eller t.o.m en BSOD.

2 saker om felrättning:

1. felet måste upptäckas, görs mha paritetscheck
2. felet måste rättas, görs genom omläsning från källan

Finns teoretiska beräknar hur ofta spontana bitfel kan uppträda. Min uppfattning är att det är så sällan att jag kan leva med det. Dock inget banken kan acceptera, hoppas jag.

Jag tycker även att ZFS är bra på att detektera intermittenta problem med lagringen. Som exempel har jag haft glappande SATA-kontakt som visat sig ibland. Eller då jag hade gamla hårddiskar som gick något varma och då gav tillfälliga rapporterade fel från ZFS som sedan försvann när jag bättrade på kylningen. Då syns det som att det förekommit fel men att ZFS reparerat felen och datan är intakt (om man har tur så att data kan återskapas från redundanta diskar). Det kanske funkar bra även med andra system men jag är nöjd med hur ZFS sköter om detta. Kanske kan något fel berott på att jag inte haft ECC men i det stora hela känns det som att ZFS ändå räddat mer data än det har förstört.

1. Intressant vore om någon vill beskriva hanteringen om/när en Raidz disk totalhavererar, vilket lär hända förr eller senare. Att ratta ett datalager när allt funkar e ju en sak men VET du vad du gör när kraschen kommer.

Finns exempel på kraschscenarier där man inte lyckats återställa korrekt, mitt förslag är att man övar på detta INNAN man fyller diskarna med data så man VET EXAKT hur man gör i ett skarpt läge.

2. FreeNAS med zfs - om du har säg 2 st uppsättningar med raidz-diskar som du kör en i taget, den andra ligger på hyllan. Anledningen kan vara att du inte har plats för allt samtidigt. VAR sparar FreeNAS konfiginfo om dessa, jag menar när du byter arrayen från den ena till den andra så måste ju FreeNAS begripa detta.

3. En annan fundering gäller FreeNAS UTAN zfs. Har en del gammelburkar med <4 GB RAM som står och dammar (vem har inte det?). För dessa är ju zfs uteslutet då zfs kräver 8 GB+. Återstår då UFS men såvitt jag förstått försvinner en hel del av FreeNAS funktionaliteten om du inte kör zfs. Då RAID0 och RAID1 är relativt simpla tekniker undrar jag om UFS-volymer klarar detta?

1) Byter ut disken och gör zpool replace polnamn gammaldisk nydisk. Testade detta senast igår när jag avsiktligt kopplade ur en disk för att sätta i en ny. Menar du om hela arrayen totalhavererar så att redundansen inte räcker till att reparera data så blir det förstås att bygga den på nytt och återställa filer från backup. Håller med om att man bör öva sig på detta så man vet innan hur man ska göra.

2) Detta sparas på diskarna självt. zpool export polnamn och lägg dem sedan på hyllan. När man kopplat in dem igen kör man zpool import. Spelar ingen roll vilken ording man kopplar in dem eller vilket kontrollerkort man kopplar dem till, den hittar infom på själva diskarna (de har väl någon id-kod lagrat på sig). Detta testade jag också senast igår (även om jag inte lade diskarna på hyllan, valde att exportera arrayen innan jag började joxa med diskarna).

3) ZFS funkar med 4GB RAM och även mindre så det kräver inte 8GB+. Det rekommenderas 8GB+ men jag har själv kört filservern med 4GB RAM, hade då i och för sig bara 5 stycken 1TB-diskar men det gick bra. Körde inte FreeNAs utan FreeBSD och Opensolaris. På freeBSD fick man tweaka inställningarna lite för att det skulle lira stabilt och snabbt med 4GB RAM men det är fullt möjligt. Jag har inte testat UFS-volymer så det får någon annan svara på hur det är i praktiken men har för mig det finns stöd för mjukvaruraid även med UFS. Jag hade nog personligen hellre kört Linux med mdadm, LVM och ext4 än FreeNAS med UFS på maskiner med mindre än 4GB RAM men det beror väl på vad man är van med och gillar bäst. Har filosofin att har man backup på de viktiga filerna så spelar det mindre roll om något pajar, det går alltid att återställa igen.

4. Hur mycket CPU-kraft drar zfs? Duger en singleCPU på 2 GHz eller ska man dra till med en Quad på 4*3 GHz? Att skyffla data borde en P3:a klara men allt i FreeNAS krypteras väl å de kan ju dra en del kräm?

Beror på VAR bitfelet inträffar. Förstörs arrayens metadata kan den bli korrupt, möjligen är metadatat redundant och kan repareras?

Som framgår av artikeln finns INGA dataräddningsprogg till zfs - vilket är illa, mycket illa.
Hur många har inte räddat data med 3:e partsprogg på sina NTFS/FAT partitioner. Det kan man tydligen glömma om man får motsvarande problem med zfs.

Misstänker du RAM-problem oavsett ecc eller ej -> kör Memtest86+ i några timmar då å då.

Glöm inte att redundans är inte isf backup, så har du det kan du somna om.

5. Fråga till er med erfarenhet av zfs. Hur ofta rapporterar zfs ecc-fel? Fråga till alla utan eccRAM - hur ofta har ni fått en korrupt array pga ecc-fel?