Hårdvaruraid vs ZFS, på hemmabygge?

Calimero,
Det finns en hel räcka saker du måste göra om du ska sätta upp CIFS. Här står alla redovisade på ett enkelt sätt.
http://blogs.sun.com/icedawn/entry/bondin

Samba kan du sätta upp via denna hemsida:
http://blogs.sun.com/observatory/entry/accessing_windows_shar...

Emigrating12
Skulle vi inte släppa det där "min är bättre än din"? För all del, du kan enkelt byta hårddiskarna till större i ZFS. Och du kan addera grupper enkelt. Så allt det du precis gjort, kan man även göra i ZFS.

Jag skulle definitivt inte själv köra 10 st diskar i en enda raid, det blir för låg säkerhet för min smak. Att köra 15 diskar i en enda raid vore katastrof. Ju fler diskar, desto större är risken att en kraschar. Om du kör få diskar i varje grupp så har du mycket högre säkerhet. Mycket högre redundans.

T.ex. om du har 1000 diskar i en serverhall och det är 0.1% risk att en disk kraschar så är det 63% risk att en disk kraschar per dag.

Alltså, även om du har en mycket liten risk för krasch, har du många diskar så behöver du mycket högre redundans. SUNs lagringsexperter rekommenderar emot att man kör ett enda stort Raid med många diskar. Bättre köra flera små raids, sammanslaget till ett enda stort lagringsutrymme.

Men helt klart, det är lite fräckt att kunna utöka en befintlig Raid, såsom du gjort!

Jookeer,
Just nu kan du inte ändra på en befintlig grupp, men den funktionaliteten är på väg. Dock är det lågprioriterat eftersom SUNs primära kunder är stora aktiebörser och stora miljardföretag där ingenting får krascha. T.ex. hela nordiska aktiebörsen kör på Solaris och har gjort det länge, jag vet dock inte om de kör ZFS. SUNs enterprise kunder är inte intresserade av att minska sitt lagringsutrymme genom att ta bort en disk. De lägger istället till ett gäng servrar med massa lagringsutrymme då och då.

Däremot om det är så att du vill lägga till antal diskar senare så kan du göra något liknande detta i stället (har jag för mig). Du skapar ett ZFS raid med 1 disk, och skapar 4 partitioner på disken. När du fått en ny disk, så byter du en partition mot den nya disken istället. Så då har du nu en ZFS raid med den gamla disken (som har 3 partitioner) kombinerad med den nya disken. För varje ny disk, så minskar du antalet partitioner med en och byter partitionen mot nya disken istället. Till slut har du en ZFS raid med 4 diskar.

Eller nåt sånt.

Ok, jag har nu fått mera information. Det som är bold ovan, stämmer inte. Han testade det på en HW raid och trodde det funkade. Men lagringsexperterna har förklarat att hans test var felaktigt, eftersom han bara testade en typ av fel som alla HW controllers klarar av att detektera. Man ska testa på ett annat sätt, och det har inte gjort.

Mera information om Raid-5, och Raid-6 (som folk här efterfrågat):

"ECC theory tells, that you need a minimum distance of 3 to correct one error in a codeword, ergo neither RAID-5 or RAID-6 are enough: you need RAID-2 (which nobody uses today).

Raid-Controllers today take advantage of the fact that they know, which disk is returning the bad block, because this disk returns a read error.

ZFS is even able to correct, when an error in the data exist, but no disk is reporting a read error, because ZFS ensures the integrity from root-block to the data blocks with a long checksum accompanying the block pointers.

A disk can deliver bad data without returning a read error by
- misdirected read (bad positioning of disk head before reading)
- previously misdirected write (on writing this sector)
- unfourtunate sector error (data wrong, but checksum is ok)

These events can happen and are documented on disk vendors web pages:

a) A bad head positioning is estimated per 10^8 to 10^9 head moves.
=> this is more than once in 8 weeks on a fully loaded disk

b) Unrecoverable data error (bad data on disk) is around one sector per 10^16 Bytes read.
=> one unrecoverable error per 177 TByte read.

OK, these numbers seem pretty good, but when you have 1000 disks
in your datacenter, you will have at least one of these errors
each day...

Therfore: Use ZFS in a redundant configuration!"

Och fick en intressant länk om "md" och Linux och NAS (Linux lösningen har t.ex. maximalt 32 snapshots) och hur man t.ex. addar diskar, varför diskar kraschar två i taget samtidigt vilket kan bero på att "md" har begränsningar, etc:
http://www.nber.org/sys-admin/linux-nas-raid.html

Angående om HW raid är säkert så sade lagringsexperterna följande saker:
Det var en enda person som sade att Raid 6 var säkert på hans Areca 1261ML kontroller, men det stämde tydligen inte vid närmre kontroll. Och alla andra personer/länkar/källor pekar på olika former av brister i HW raid säkerhet. Så jag fick inga svar från folk som sade att HW raid var säkert, alla var överens: HW raid är osäkert. Speciellt var det flera personer som ansåg att just Raid-5 bör undvikas. Möjligen kan Raid-6 komma ifråga. En del anser att man inte ska köra Raid med för många diskar, och även länken ovan säger att man ska inte köra för många diskar i en raid, pga det sänker säkerheten. Det var även folk som menade att HW raid är helt enkelt lite mjukvara som körs på en klen CPU. Och mjukvaran är dessutom stängd. "Lycka till med closed source", typ.

Och jag har presenterat bl.a. länkar från CERN som säger att de fick silent corruption - HW raidet märkte inte att skrivningen blev felaktig. Det upptäcktes först efter en kontroll, CERN folket visste exakt hur datat skulle se ut, och det stämde inte. Datat diffade.

Calimero,
Kan du skriva ned lösningen i OpenSolaris tråden på Linux avdelningen kanske? Där diskuterar vi ju ZFS hemma filservrar och även andra kanske vill veta hur man gör?

Jag själv föredrar stabilitet och tekniska fördelar framför ett snygg gui, så jag föredrar ett serverOS som Solaris framför Apple OS X, trots att det är gratis och att jag är en fattiglapp. Om Solaris duger åt aktiebörsen, så duger det åt mig. Det jag gillar med Solaris är att det skalar bra. Man kan köra det på Asus EeePC, hemma servern och ända upp till megastora installationer där man driftar typ kärnreaktorer, aktiebörser, etc. Tänk om jag lärt mig Windows och sen måste jag börja jobba på aktiebörsen, då måste jag lära om från början med Solaris. Nu kör jag Solaris hemma, så jag slipper lära om, om jag måste jobba med riktigt seriösa installationer. Jag kan redan Solaris. På stora installationer är det oftast nån Unix variant.

Fast iofs så är både Apple och Solaris är Unix, så mycket är detsamma. Man slipper faktiskt lära om. Det vore skillnad om man bara kunde Windows, då skulle man börjat från noll om man går till Unix. Det vore inte bra, det är bra att kunna lite om alla OS, tycker jag själv.

(Om man vill läsa lite om Solaris så kan man läsa denna tråd. Mycket som står här, finns skrivet där. Men jag pratar även om SunRay, DTrace, Linux prestanda vs Solaris prestanda, och annat:
http://www.sweclockers.com/forum/showthread.php?s=&threadid=8... )

Angående ZFS så är det SUN som utvecklat det, och sköter all utveckling. Apple och FreeBSD har portat ZFS från Solaris, de båda har antagligen inte bidragit med mycket kod (om någon alls).

Angående roadmap så vet jag inte var det finns. Däremot vet jag att på ZFS mail listor, diskuteras att man ska kunna lägga till/minska diskar (på en grupp av diskar) i ett ZFS raid. Det pratas även väldigt löst om deduplicering(?), dvs många filer har ju mycket gemensamma data. T.ex. doc formatet, har alltid en header som ser ut på ett visst sätt. Då är det onödigt att lagra headern i varje doc fil. Det räcker att lagra bara en header. Så om en fil har en bitsträng, så slipper man lagra den bitsträngen i varje fil. Det räcker att en enda fil lagrar den bitsträngen, och alla andra filer pekar på bitsträngen. Alltså en form av automatisk komprimering. (Detta ska inte förväxlas med att en partition är komprimerad, det finns sedan länge i ZFS. Man säger att en partition ska komprimeras, och väljer komprimeringsmetod/algoritm-gzip? och allting man kopierar dit blir automatiskt komprimerat. Det finns vissa siffror som säger att man får snabbare överföringshastighet om man komprimerar datat därför att det går snabbare att läsa lite data från disk och packa upp det i det snabba RAMminnet, än att läsa mycket data från den långsamma disken)

Sen är det massa andra småsaker. Jag känner inte riktigt till allting som de vill lägga till i ZFS.

Yonkas,
Jag tycker det är strategiskt smart att Apple väljer ZFS. Apple slipper utveckla och underhålla koden själva, på en sån här komplex produkt. SUN testar ZFS riktigt ordentligt och det är extremt viktigt att testa kod och funktioner, men det tar mycket tid och resurser. Nu slipper Apple allt detta jobb som SUNs ZFS tester gör varje natt (flera år gammal info, nu är detta ytterligare förbättrat antagligen):

"Nightly “ztest” program does all of the following in parallel:
* Read, write, create and delete files and directories
* Create and destroy entire filesystem and storage pools
* Turn compression on and off (while FS is active)
* Change checksum algorithm (while FS is active)
* Add and remove devices (while pool is active)
* Change I/O caching and scheduling policies (while pool is active)
* Scribble random garbage on one side of live mirror to test self-healing data
* Force violent crashes to simulate power loss, then verify pool integrity

Probably more abuse in 20 seconds than you’d see in a lifetime
ZFS has been subjected to over a million forced, violent crashes without losing data integrity or leaking a single block "

Apples val av ZFS betyder även att man kan ta ett ZFS raid från Solaris och stoppa in i en Apple maskin, och tvärtom. ZFS lagrar endian neutralt, mao spelar det ingen roll om du kör Solaris på SPARC eller x86, FreeBSD eller Apple. Det är bara att ta ut diskarna och stoppa in dem huller om buller i den andra datorn och göra "zpool import" så är det klart. Detta är svårt att göra med HW raid. Båda datorerna måste utrustas med HW kort, och beroende på cpu arkitektur så lagras data olika pga big endian eller little endian. Med ZFS slipper man alla dessa strul. Behöver inte installera HW kort eller nånting.

Det är även smart att FreeBSD valt ZFS. Ju flera OS som har ZFS, desto kompatiblare blir vi alla. Som Unix användare är det strul att mounta andra filsystem, som NTFS och sånt. Drömmen vore att bara mounta på, oavsett vilket OS. Vi kanske kommer dit?

Gör det. FreeBSD är ett mycket bra OS med stabil kärna, och jag körde det själv tills Solaris öppnades.

Jag vet inte hur ZFS versionerna skiljer sig åt. Men folk har kört tidiga ZFS versioner utan problem. Jag tror ZFS funkar mycket bra tillsammans med FreeBSD.

Antagligen kan man gifta ihop Solaris och ZFS ganska bra. Men även FreeBSD och ZFS borde gå bra. Det finns folk som kör sajter på ZFS och FreeBSD. Jag tror inte du behöver oroa dig om du provar FreeBSD.

Här är en ascool ny video som visar vad DTrace kan göra i kombination med lagring, i detta fall är det ZFS på SUNs nya storageservrar 7000.
http://storagemojo.com/2009/01/02/shh-disk-drive-at-work/

Sens moral, diskar är känsliga för vibrationer och DTrace kan monitorera precis allting som händer i datorn. Man kan alltså optimera system och program på ett helt nytt sätt som man aldrig kunnat tidigare. Revolutionerande. Faktiskt.

EDIT: En intressant liten sak. Jag ska köpa 5 st terabyte diskar till min ZFS raid och tittar på olika drivar. T.ex. WD Caviar Green Power:
http://www.komplett.se/k/ki.aspx?sku=391606&view=detailed#Pro...

När man bläddrar runt bland disk beskrivningarna, så står det längre ned under "detaljerad specifikation":

"Pålitlighet
Oåterkalleligt fel 1 per 10^15"
Det verkar alltså vara så att med jämna mellanrum så disken råkar ut för fel som den inte kan korrigera.

Om inte disken korrigerar, så kommer ZFS att göra det. Det är precis det jag försökt säga i flera inlägg här, att ZFS märker fel som varken disken eller kontrollerkortet själva märker.

"One of the design principles we set for ZFS was: never, ever trust the
underlying hardware."

Så ZFS litar inte på att varken disken eller kontrollerkortet gör ett bra jobb. ZFS litar inte på någon, även om någon säger att allting gick felfritt. ZFS lider av paranoja och sparar checksummor för allting, på varje disk. Viktiga checksummor sparas i dubbla eller tredubbla kopior på varje disk. Sen kollar ZFS upp varje liten grej som sker, om det verkligen blev korrekt eller måste korrigeras.

(Se detaljer på
http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf
Finns även en liten roadmap, t.ex. kommer ZFS stödja kryptering om 10 veckor, i Solaris Express build 109. Nu är build 104. OpenSolaris bygger på build 103. En ny Solaris Express build kommer varannan vecka.)

Det värsta är nämligen när disken eller kontrollerkortet gjorde fel, men tror att allting gick bra. Får man en felrapport så korrigerar man felet enkelt. Men vad händer om man får en lyckad rapport men det egentligen blev fel? Det är såna fel som är värst.

Det är som att man är överste, och ens soldater rapporterar att allting gick bra - men de ljuger, eller blev själva lurade att tro att operationen lyckades. Eller som att man tittar på spisen och den ser avstängd ut och man går iväg, men i själva verket är det fel på spisens lampa och spisen är egentligen på. Eller att man ringer in sista dagen och kollar att skatteverket fått in min skattedeklaration vilket bekräftas, men det är i själva verket fel på skatteverkets datorer och posten har slarvat bort din deklaration men posten har inte meddelat dig eftersom posten själva inte vet det. Det är illa att få ok rapport både från disk och kontroller kort, när det egentligen gått fel.

Caviar GP vet jag inte så mycket om. Det är väl bra att den drar lite ström eftersom den är 5400 RPM. Men den blir därför långsammare. Själv bryr jag mig inte så mycket. Kör man ett ZFS raid så uppnår man lätt flera hundra MB/sek, det brukar räcka för hemmabruk? Kanske blir även accesstiden lidande, men jag bryr mig inte så mycket om det heller. Ett raid är tillräckligt snabbt för husbehov redan med 5400 varvare, tycker jag. Det kanske går ytterligare lite snabbare med 7200 varvare, men alla raid är ju väldigt snabba.

Men jag kör ZFS pga säkerheten. Inte pga snabbheten. Hellre långsamt och säkert, än snabbt och korrupta filer. För annars kan jag lika gärna köra Windows Home Server som korruptade filer i ett halvår, innan patchen slutligen kom som fixade den buggen. Livsfarligt att använda den som lagringsserver, och den är långsam. En filserver ska vara säker. Snabbhet är bara en bonus. Tänk om jag lagt många timmar på datat? Kanske skrivit på en roman eller en doktorsavhandling i 5 år och datat försvinner? Eller privata foton på min avlidna mamma? (Det är inte alltid man tagit backup). Vad är viktigast, säkerhet eller snabbhet?

Du får välja:
A) 30MB/sek, 100 ms accesstid, och dina data är råsäkra. Kan inte korruptas. Enterprise aktiebörser kör detta system.
B) 900MB/sek, 3 ms accesstid, och det är 0,01% risk att dina data korruptas.
Jag själv väljer A) alla gånger. Det finns säkert användning för fall B) oxå, men jag själv tycker A) passar bäst för mig. Jag vågar inte lagra filer annars. Väljer jag B) måste jag ju skaffa en till lagringslösning som är säker.

Men nu råkar jag dessutom få grymma prestanda och massor av crazy funktioner, på köpet med mitt ZFS raid. Men "köpet" är gratis och kräver ingen extra hårdvara.

Jag själv lägger ingen vikt vid snabbhet när jag väljer raid. 5400RPM diskar går bra för mig.

Löjligt billig server. 2500kr. Jisses. Det vore kul om du postade dina prestanda siffror senare här. Jag tror det är bra att du ökar till 4GB RAM:

"ZFS is like a big RAM cache. The more RAM the better. You would be surprised how little disk activity there can really be on systems with a lot of RAM
as long as synchronous writes are avoided. As a result, some common
scenarios mostly exercise RAM rather than the disk channel.

Unless you need a higher power CPU for other purposes, a ZFS-based
server should focus on maximizing installed RAM."

Folk säger att med 8 GB så är raidet nästan totalt idle. Det är lite skönt med en automatisk och fet RAM cache, en RAM cache är ju skitsnabb. Blir som en SDD disk men den är optimerad för ZFS bruk. Och du behöver inte ställa in nåt eller sköta om den. Fire and forget, dvs stoppa in RAM och forget. ZFS är extremt lättskött som tur är.

Om något program behöver RAM, så släpper ZFS loss RAMet direkt. Men ZFS snor allt RAM den får tag på, för att agera automatisk cache.

Här är det uppåt 2GB/sek, men i detta fall beror det på RAM. Stoppar du i 48 SATA diskar, så får du oxå 2GB/sek, men då är det diskarna som levererar det.
http://www.markround.com/archives/35-ZFS-and-caching-for-perf...

Jag byter just nu mina 4 st 500GB diskar i ZFS raid mot en annan ZFS raid med 5 st Samsung F1 terabyte. Jag kopplade in TB Samsung diskarna och Solaris rapporterade att en 500 disk inte funkade i det gamla ZFS raidet, pga jag bytte plats på en 500GB disk och en 1TB disk. ZFS sa att raidet funkar, men en disk är ur funktion. Den väntade sig en 500GB disk, men fann en oformaterad TB disk istället. Den riktiga 500GB disken låg på en helt ny SATA slot. Jag skrev "zpool export oldRaid" och "zpool import oldRaid" och ZFS detachade det gamla Raidet och plockade in de diskarna igen, men den scannade igenom alla diskar så det blev rätt nu. Och allting funkar nu bra. Just nu kopierar jag alla data på 1.5TB från gamla raidet till det nya 4 TB raidet.

1. RAM är viktigast. ZFS drar lite cpu, men inte mycket. Det sägs att den drar lika mycket cpu som ett vanligt filsystem numera eftersom koden optimerats. En RAM disk gör mycket mera för snabbheten. Det är som en SSD disk, fast RAM är mycket snabbare än SSD. Plus att ZFS cachar på ett någorlunda intelligent sätt.

2. Ja det kan du. Men ZFS raidet kommer skapas som den minsta disken. Typ: du har 100GB, 100GB, 250GB och 250GB. Då kommer det skapas en ZFS raid med 100 GB x 4. Slattarna kommer inte att användas tyvärr. Då kanske du kan skapa 2 olika grupper istället: en grupp om 100GB x 2 och en annan grupp om 250GB x 2 och sen adda båda grupper till en enda ZFS raid.

1. ZFS tar hand om cachen själv. Du behöver inte göra nånting alls.

2. Jepp.

3. Ja, men då kommer den in som en egen grupp. Det är inte bra, eftersom den gruppen inte har någon redundans. ZFS raidet kommer sprida data över alla grupper. ZFS vill att varje grupp ska kunna krascha minst en disk. Om du addar en ensam 50GB disk och den kraschar, så blir det problem. När du addar en grupp, så bör du adda minst två diskar. På så sätt kan en disk krascha utan problem i varje grupp.