Hårdvaruraid vs ZFS, på hemmabygge?

Ok, det verkar vara så här.

En modern disk har från början, redan flera hundra tusen sektorer avdelade för sånt här. Om disken börjar krympa, dvs de sektorerna börjar ta slut så betyder det att disken är i mycket dåligt skick och bör omgående bytas ut. En normalfungerande disk krymper inte, har flera hundra tusen sektorer redan använts, så är takten alldeles för hög för en normalfungerande disk.

Aj då! Detta var inte bra! Jaha. Det var ju kul. Så om min ZFS array strular, så måste jag skaffa exakt en likadan disk, eller större, för att byta ut den trasiga?? Illa för oss hemanvändare. Ok, om man kör SUN hårdvara och är då garanterad att SUN diskarna kommer att fungera i en ZFS raid, men vi hemanvändare har inte råd med SUN hårdvara.

Jaja. Jag får väl hoppas att SUN fixar att man kan krympa och öka pooler snart så slipper vi det här problemet. Men nu vet jag i alla fall att jag ska noga kolla upp att jag får minst lika många sektorer på min replacement disk. Och köper jag en större disk så är jag garanterad att det funkar utan problem. Jobbigt för de som kör de största diskarna som finns på marknaden - de kan inte köpa en större disk. De måste köpa en exakt likadan disk som de andra diskarna. Jobbigt att tvingas leta upp en exakt likadan disk, eller större. Jag trodde man slapp sånt här med ZFS, det är ju nästan som att tvingas köpa exakt ett likadant HW raid kort om kortet går sönder. Och det är ju ett argument emot HW raid och ett argument för ZFS - men nu försvinner det argumentet. ZFS verkar lika jobbigt. Här ser vi ett klockrent exempel på att trots flera års utveckling så är filsystem komplexa att göra, mao ZFS är ett ungt filsystem som fortfarande saknar essentiella funktioner.

Jaja. Nu vet jag hur jag ska gå runt detta problem i alla fall. Tack som faen för att ni tog upp det! Det skulle kunnat orsaka strul, om jag inte kände till detta. Tack.

Jamen det är ju ändå lite jobbigt att inte kunna blanda lika stora diskar från olika märken fritt i ZFS. Jag visste inte ens att detta problem existerade, jag trodde alla diskar var exakt lika stora. Men istället måste man nu använda exakt samma modell av diskarna, eller kolla upp antalet sektorer i replacement disken innan man använder disken - om det är annat märke. På detta sätt slipper man alla problem. Skönt att det finns en enkel work-around i alla fall. Även om den är lite jobbig.

Himlar vad bra att ni ställer kniviga frågor om ZFS. Jag lär mig skitmycket i denna tråd om lagringslösningar och diskar!

Hur löser ett vanligt raid detta problem? Typ intels chipset? Hur löser billiga raid kort detta problem? Och hur gör mjukvaruraid? Kan man inte heller blanda lika stora diskar i de lösningarna?

Jag förstår att i dyrare proffs HW raid kort, så kan man blanda lika stora diskar från olika märken helt fritt. Och man kan öka på HW raidet med en disk i taget utan problem. Dessa två funktioner är ju helt klart bra. När ZFS fått dessa två funktioner, vad mera önskar man? Vad kan HW raid som inte ZFS kan? Vad mera funktionalitet är viktig? Som sagt, jag har aldrig själv sysslat med seriösare lagringslösningar, och vet inte så mycket om de problem som dyker upp.

Som jag ser det, så är detta med att TB diskar har olika antal sektorer - inget problem. Eftersom jag nu vet hur man går runt det problemet, tack vare er. Så jag kommer inte att avdela 98% av utrymmet på varje disk och strula och fixa med write cache och sånt.

Det är helt enkelt bara att noga kolla antal sektorer på den nya ersättningsdisken, innan man köper den. Och hur ofta måste man byta ut en disk i ett ZFS raid? Hur ofta kraschar en disk? Jag har aldrig råkat ut för det än. En disk i mitt raid kanske börjar strula om 2-3 år? På 2-3 år hinner mycket funktionalitet i ZFS läggas till. Och om den funktionaliteten inte finns om några år, så är det bara att kolla antal sektorer vid diskköp. Jag ser detta inte som ett stort problem, ärligt talat.

Detta är däremot ett problem om man hela tiden köper nya diskar och blandar dem friskt med de gamla. Men jag själv uppgraderar inte mina diskar hela tiden. Jag gör inte sånt. Så för mig är detta inget problem.

Ett problem har man, när man inte känner till lösningen. Men vi känner till lösningen.

Beh, Pr0xy,
Jag tror ni kan fråga Ronnylov om olika konfigs. Han satt ju precis och läste in sig på olika komponenter. Ronnylov, vad säger du om dessa två herrars frågor?

Jookeer,
2) Jag har kopplat loss en disk ur min ZFS raid och körde typ en kvart. Kunde läsa och skriva data utan problem. Sen bootade jag om och kopplade in disken, då försvann meddelandet "DEGRADED" och allt funkade som vanligt. Här två korta snuttar när de kraschar diskar och ersätter diskarna, vad händer med ZFS då?
http://www.youtube.com/watch?v=CN6iDzesEs0
http://video.google.com/videoplay?docid=8100808442979626078

4) MS hade ett "revolutionerande och nytt" filsystem på gång som skulle heta WinFS. Som jag förstod det, så visade sig helt enkelt vara en databas ovanpå NTFS. Så alla filer stoppades in i databasen. Då kunde man t.ex. söka på alla video filer och få upp dem. I stort sett så behövdes inga kataloger längre, man bara körde in alla filer huller om buller, och kunde sen söka i den stora mängden data. Men WinFS kom aldrig till skott pga olika skäl. Tänk om man kunde lägga en databas ovanpå ZFS, så får man något lika "revolutionerande och nytt" som WinFS? Nåt åt det hållet var WinFS, som jag förstod det. Och eftersom det var NTFS i botten så fanns ingenting om dataintegritet i WinFS. Sånt var inte ett problem, som MS såg på saken.

På bara några år har vi gått från 500GB diskar till 2TB - mao kommer silent corruption bli vanligare och vanligare. Förrut hade vi inte många bitar i våra små diskar, så silent corruption märktes knappt. Men diskarna är större än förr och billigare än förr, och nu börjar folk använda Raid. Då blir det jättemånga bitar. Någon av bitarna kommer att flippas av misstag.

Det dröjer alltid flera år innan OS teknologi kommer ikapp. Att designa och utveckla nya filssystem tar flera år, de är så komplexa och viktiga. Det är först nu som man börjar se behovet av dataintegritet på diskar, och utvecklingen av nya filsystem har starta nu.

När det gäller minne har servrar länge kört ECC minnen. Föreställ dig folk som sade "jag behöver inte ECC minne, jag har aldrig märkt att bitar flippas i mitt RAM". Men ju fler GB RAM vi har desto viktigare blir det. Och RAM skrivs och läses och ändras väldigt snabbt och väldigt ofta. RAM bandbredden är mycket stor, det blir jättemycket bitar som ändras och läses hela tiden non stop. Man kanske läser och skriver i RAM, flera 100Giga bitar per dag även om man bara har 1GB RAM. Och nu, börjar diskarna bli stora och snabba, så då kommer vi också upp i flera 100GB bitar mot diskarna? Gör man hundratals miljarder läsningar och skrivningar per dag, så kommer nog någon bit flippas av misstag. Därför krävs ECC minne i servrar. Filsystem med dataintegritet är för diskar precis samma sak som ECC minne är för RAM.

Det är numera nya generationens filsystem på gång i Linux lägret. BTRFS, Hammer, etc. BTRFS påminner väldigt mycket om ZFS, snapshots, CoW, etc etc. Problemet är att det är i protypstadiet och det kommer att dröja flera år innan det kommer. Och då kommer det sakna funktionalitet i flera år. Kolla på ZFS, man kan fortfarande inte öka på/minska antal diskar, och diskarna måste ha lika många sektorer, som Emigrating12 m.fl påpekade. Och hur många år har ZFS funnits? Det släpptes typ för 5 år sen. Och det anses vara ett ungt filsystem, vilket märks. Ett moget filsystem är ett par decennier gammalt.

Men kanske har SUN högre krav på tillförlitlighet än vad Linux lägret har. Det är många som säger att Linux koden är si och så, och att SUN aldrig skulle släppa ifrån likadan kvalitet på sin kod. Om SUN schabblar så kan de fet stämmas. Det är svårare att stämma öppen kod. Stämmer de RedHat, så kan de referera vidare till Linus Torvalds, som kan referera vidare till att han bara mergar kod, etc. Det finns ingen tydlig ansvarig att stämma i öppen kod, så SUN måste ha bra kvalitet på sin kod - de kan inte slingra sig.

Det kommer nya generationens filsystem snart. Men det kommer dröja flera år innan de är här. ZFS utvecklas i rasande fart och nya funktioner läggs till hela tiden. I sinom tid kan man lägga till och minska antal diskar i ett raid. Och att diskar inte är exakt lika stora kommer också kunna hanteras av ZFS, eftersom samma funktionalitet kommer kunna lösa båda två problemen.

Emigrating12,
Det är illa att samma märke diskar från samma leverantör kan ha olika antal sektorer. Men du verkar mena att leverantörerna börjar standardisera nu, så det är inte lika stort problem som förrut. Det låter positivt. Men ändå, nu tycker jag som ni, att ZFS ska kunna öka på antal diskar och minska dem - eftersom då löses två problem. Tidigare tyckte jag det inte var viktigt. Men först nu förstår jag varför du tjatade om det tidigare.

5) Om strömmen till ZFS försvinner så kan inte t.ex. halva datat skrivas på disk och andra halvan försvinna ut i tomma intet pga strömmen gick precis vid det tillfället - vilket resulterar i inkonsistenta data och att du aldrig får rapport om det vid omboot. Detta scenario inträffar inte med ZFS. Ett vanligt filsystem kan rapportera att datat är nedskrivet samtidigt som den skriver data - och precis då, går strömmen så datat hinner inte skrivas ned. Halva datat försvinner - och du tror att datat blev nedskrivet.

Skälet att ZFS inte har detta problem, är att ZFS skriver ned hela datat, och som sista steg uppdateras pekaren till de nya blocken. Så om ZFS bara skriver ned halva datat och strömmen går, så får du ingen rapport om att skrivningen lyckades (men det får du med andra filsystem). Först när allting är klart, så rapporterar ZFS att det är klart.

Samma sak om du ändrar data. Det gamla datat ligger kvar på disken. Och ZFS skapar en kopia som den ändrar i, och när allting är ändrat, så uppdateras pekaren att peka på det nya ändrade datat. Det gamla datat är fortfarande kvar, en stund till. Andra filsystem börjar ändra i originalfilen, och så försvinner strömmen mitt i ändringen och du tappar filen och måste gå till din backup. Med ZFS inträffar inte detta. Data consistency är garanterad. Som journalförande filsystem, typ. Men data consistency är alltid garanterad med ZFS, och du måste inte återspela hela journalfilen i timmar. Vid reboot så är det bara att fortsätta direkt där du var. Ingen fsck i veckor eller så. Du kommer aldrig få msg att en skrivning gick bra, när i själva verket bara halva datat skrevs ned. Du blir inte lurad av ZFS.

Detta kallas Copy On Write, CoW.

Angående ditt experiment. Som jag förstått det, så är risken för total data korruption/ej recoverable errors mycket liten i raid. Får du ett sånt fel där allting skiter sig, så kan du alltid gå till backup, du vet att det blev problem med en viss fil. Det som däremot är ett problem med stora raids med många läsningar är _silent corruption_. Dvs, data som inte skrevs ned som de skulle - och du får aldrig rapport om det. SUN presenterar flera fall när tyst data korruption kan inträffa med HW raid.

Det finns HW raid folk som provade sina setups och ingen korruption kunde detekteras. T.ex. beskriver en HW raid person ett av sina experiment:

"We did a few tests in a 16 disk RAID6 where we wrote data to the Areca RAID, powered the system down, pulled out one disk, inserted it into another computer and changed the sector checksum of a few sectors (using hdparm's utility makebadsector). The we reinserted this into the original box, powered it up and ran a volume check and the controller did indeed find the corrupted sector and repaired the correct one without destroying data on another disk (as far as we know and tested).
...
I know that our Areca 1261ML does detect and correct those errors - if these are single-disk corruptions"

Och svaret:

"You are talking about diffrent types of errors. You tested errors that the disk can detect. That is not a problem on any RAID, that is what it is designed for.

He was talking about errors that the disk can't detect (errors introduced by other parts of the system, writes to the wrong sector or very bad luck). You can simulate that by writing diffrent data to the sector"

Ett annat svar:

"you did not simulate a silent data corruption error. hdparm --make-bad-sector just introduces a regular media error that *any* RAID level can detect and fix.
...
However I pointed out that he may have tested only easy corruption cases (affecting the P or Q parity only) -- it is tricky to simulate hard-to-recover corruption errors..."

Mao, det är svårt att testa HW raid på ett korrekt sätt. Chansen finns att man testar något som HW raid kan korrigera. Och sist, denna länk:
http://blogs.sun.com/constantin/entry/zfs_saved_my_data_right

I vilket fall som helst, om du kört stora HW raid länge och aldrig haft problem, så varför byta? "Don't fix what is not broken". Du vet nog vad du sysslar med. Du vet vad som passar dig bäst, det vet ingen annan. Möjligen kan du bara för att hålla dig uppdaterad med olika tekniker, slänga in OpenSolaris i gammal PC och experimentera lite vid sidan av, med iSCSI och sånt.

Jookeer,
"Även med ZFS kommer man vid strömavbrott att tappa data, säg att det ligger 100 uppdateringstransaktioner i kö till en viss volym eller databas och några av dessa vid strömavbrottet inte hunnit loggats så klarar ju inte ZFS detta, vilket ju är självklart."

Ja absolut är det så. Men skillnaden är att du vet om att datat aldrig skrevs till disken. Om strömmen går så kommer ZFS upphöra att fungera. Men tillståndet på disken kommer alltid vara konsistent. Det är det, som är skillnaden. Du kommer inte få en rapport att "det gick bra" när det inte gick bra. Antag att du har ett vanligt Linux filsystem med många användare som läser och skriver och strömmen går. Då kommer många skrivningar bli halvgjorda. Vilka skrivningar måste dubbelkontrolleras? Vilka skrivningar hann avslutas? Vilka gjordes till hälften, när strömmen gick? Med ZFS slipper du sånt. Du vet att allt som skrevs ned på disk, är korrekt. Data consistency är garanterad.

Det är ungefär som jag frågar:
-Hur går diskandet?
-Det går bra jag är klar nu, säger han och håller samtidigt på att diska och han har bara kommit halvvägs. Men tänk om han blir avbruten mitt i diskandet? Han kommer inte ge dig en ny rapport: "öhh... jag blev avbruten i diskandet, jag är inte alls färdig". Du har ju fått hans rapport och du tror disken är klar.

ZFS skulle göra så här istället:
-Hur går diskandet?
*tyst*... *tyst*.... (och först när disken är klar) säger ZFS:
-Det går bra, jag är klar nu.

Så du vet att disken är färdig. I första scenariot vet du inte att disken är färdig. I händelse av krasch, så måste du kontrollera alla kockar och se hur många som verkligen hann diska klart, och hur många som sa att de diskade klart men inte alls hann diska klart. Så du måste säga åt de kockar som inte hann klart, att slutföra disken. Men först måste du identifiera dem. Eller, så är det vanligare att säga till alla kockar att diska om allting på nytt. Så även de kockar som verkligen hann diska klart, måste upprepa disken. På så sätt kan du vara säker på att all disk verkligen är färdig.

Antag du har massa skrivningar mot en databas, vilka är gjorda och inte gjorda? Med ZFS slipper du det problemet. Med andra filsystem måste du upprepa alla ändringar innan krasch, alla ändringar loggas först i en fil innan de verkligen äger rum på disken (journalförande filssystem), det kan ta timmar att åter spela upp alla senaste skriv operationerna - så att både loggfilen och disken överensstämmer. Sen bör du göra fsck, det kan ta en vecka.

Angående silent corruption, det har aldrig varit ett stort problem tidigare. Men tidigare hade vi inte så här stora diskar. Ju fler bitar vi har tillgång till, desto vanligare kommer detta bli. Till slut blir data integritet ett måste.

En modern disk har idag 20% av ytan dedikerad till felkorrigeringskoder. Det skulle inte behövas om korruption aldrig inträffar. Jag tror att om ett tag så kanske 25% av ytan används till felkorrigering. Mao, blir hela tiden stora mängder fel på dagens stora diskar.

Sen tror jag nog att vi hem användare kan leva med att en MP3 låt missar en bit här och där, ett blink på skärmen klarar vi av. Värre är det om du kör en aktiebörs, och en 1a råkar bli en 2a. Men absolut, jag tror att än så länge är detta inte ett stort problem. Jag själv har aldrig träffat på detta, vad jag vet. Men när 10GB diskar och stora raid blir vanliga, så kommer vi träffa på dessa fel oftare. Ju fler bits, desto mer sårbara blir vi. Jag har aldrig haft så här stora diskar förrut i mitt liv.

Stora enterprise lösningar, kärnrobotar, kontosaldon på banker, etc kör ju annat än NTFS eller ext3. De kör Veritas och jag vet inte vad de heter. Men de är svindyra. En del enterprise företag har dock börjat gå över till ZFS. En bank slutar med sin dyra lösning och går över till ZFS:
http://blogs.sun.com/openomics/entry/fast_reliable_cheap_pick...
Ett av de här lagringsföretagen har stämt SUN pga ZFS. De är livrädda för ZFS, för det är gratis.

scrub tar så lång tid som du har data. Om raidet är tomt, så går det ögonblickligen. För 3 TB data som scrubbas, tar det typ 7h eller nåt sånt. Men det gör inte så mycket, jag kan ju använda raidet under tiden. scrub går igenom alla data och kontrollerar och reparerar alla checksummor så de överensstämmer med datat.

resilver tar så lång tid som disken måste repareras. Om du har kört länge med ofullständigt raid, så kanske du hunnit lagra mycket ny data. All den data måste resilvras och det tar tid. Jag antar att det tar lika lång tid som scrub.

Jag tror det är så att hemanvändare som kör billiga diskar rekommenderas scrubba en gång/veckan och Enterprise diskar ska scrubba en gång/mån, pga högre kvalitet. Tvärtom alltså. Men jag har inte igång mitt raid så ofta, så jag scrubbar sällan. En gång varannan månad eller så. På min förra raid med 4 st 500GB diskar som jag hade drygt ett år, som alltid var igång, scrubbade jag totalt 4 ggr kanske. Alltså, jag litar på nya hårddiskar. Jag har inga dåliga erfarenheter av nya diskar, eftersom jag inte har så stora erfarenheter. Jag tror att om man har splitternya diskar så ska man inte behöva scrubba hela tiden. Att scrubba är för den nojjige, typ. Men det förstås, skulle jag driva ett företag skulle jag scrubba ofta. Däremot gör jag "zpool status" dagligen för att se om ZFS detekterat några läs eller skrivfel.

Angående att hantera diskar som fallit bort. Man kan adda en "hot spare", alltså en tom disk som står i standby. Den disken kommer automatiskt att ta över den trasiga diskens roll så raidet blir helt igen, vid diskkrasch. Men det är ju en dyr lösning att ha en extra stand by disk.

Kanske är det bästa som du föreslår, att "grep" zpool status kommandot och skicka mail när det knasar? Jag själv håller tummarna. Jag har aldrig varit med om att en disk kraschat. Jag har ju splitter nya diskar. De ska hålla bra. Moderna diskar har grym MTBF. Skulle jag byggt ihop raidet med gamla diskar, så skulle jag scrubba och vara nojig.

Ok, det verkar som man kan slå på casesensitivity=mixed som default när man skapar en zpool:

# zpool create -O casesensitivity=mixed foo c1d1 c2d2
# zfs get casesensitivity foo
NAME PROPERTY VALUE SOURCE
foo casesensitivity mixed -
------------
You can check whether it's set with:
$ zfs get casesensitivity pool/filesystem

If you're using CIFS, you need that to return "mixed" or "insensitive". If it returns "sensitive", it will cause you problems.

Unfortunately there's no way to change this setting on an existing filesystem, so if you do have the wrong setting you'll need to create a new filesystem and move your files over. If you have enough disk space it's relatively easy to do with CIFS:

- Create a new filesystem on the server using "zfs create -o casesensivity=mixed ...."
- Share it under a new name: "zfs set sharesmb=name=xxxx pool/filesystem"
- Move all the files (I did a cut/paste with windows explorer since this preserves permissions, robocopy would probably work too, mv in solaris might but I've not tried that)
- Delete the original filesystem and change the name the new one is shared under with "zfs set sharesmb=name=yyyy...."
- Rename the new filesystem if needed with "zfs rename"

(Används tillsammans med CIFS och Windows)

Emigrating12
Jag vet inte om du verkligen testar silent corruption nu. Det verkar som du påpekar, svårt att testa det korrekt. Jag kan för lite för att uttala mig om saken. Men i vilket fall som helst, så tror jag inte man råkar ofta ut för silent corruption. Jag tror det endast kan vara ett problem i system som skyfflar mycket data hela tiden utan avbrott. Jag själv har aldrig märkt att jag drabbats av det.