[Utbrutet stickspår från en annan tråd — Här diskuteras ZFS, bit rot och annat - mod]

Moderator informerar om denna tråd

*Meddelanden utbrutna* från Vilken typ av Raid5 el Raid6 lösning. Tips?. Detta långa stickspår anser jag inte hjälpte trådskaparen, men gör ett försök med att ge det en egen tråd om det finns mer att diskutera.

/phz

----------------------------------

ZFS hjälper mot oavsiktlig radering. Du måste använda "snapshots", det funkar som Apple Time Machine.

ZFS är gratis och du behöver inget extra raidkort. Istället använder du bara vanliga SATA diskar. ZFS är ett mjukvaruraidsystem som är mycket säkrare än raid kort.

Med tiden så ruttnar data sakta bort. Det börjar bli bitfel här och där, helt spontant. Mina gamla Amiga disketter funkar inte idag, de har för många fel. Datat har ruttnat bort. Detta händer även på hårddiskar, men i långsammare takt. Så om du upptäkcer att du inte kan öppna en rar fil längre, så går du till din backup, dvs din extra hårddisk i byrån. Men, tänk om de filer du backuppade redan var ruttna? Tänk om även din backup har samma ruttna fil? Eller tänk om när du kopierade filen, så blev det något knas i kopian. Har du kontrollerat att din backup funkar korrekt och inte har några trasiga filer?

Du borde göra en MD5 (eller SHA256) checksum på alla filer på din hårddisk, och sen göra en MD5 (SHA256) checksum på din backuphårddisk och jämföra resultatet. Först då kan du vara säker på att din backup funkar som avsett och att det inte är några fel eller ruttna data. Så med jämna mellanrum (kanske en gång i månaden) så bör du göra MD5 checksummor på alla dina filer och jämföra dem för att se att inget har ändrats (t.ex. data ruttnar, eller virus har ändrat exe filer, etc). Och om nån fil har ändrat sig, så måste du ta fram en korrekt fil från din backup och kopiera tillbaka. Tänk om många filer har ändrat sig, då måste du kopiera många filer.

Och sen om du ska vara säker, så borde du förvara din MD5 checksumme fil på en annan hårddisk. Tänk om din MD5 fil råkar raderas?? Så du har din MD5 fil på olika hårddiskar. Och när du uppdaterat en fil så måste du uppdatera MD5 checksumme filen på alla dina hårddiskar. Och eftersom du har flera hårddiskar, så måste du göra detta för alla diskar. Det blir många MD5 checksumme filer det.

Självklart måste du göra även detta för raid. Om du köper ett raid kort så måste du se efter att dina data inte ruttnar bort på raidet. Du måste köra MD5 checksummor på alla filer med jämna mellanrum och se att alla data är korrekta. Och förvara MD5 checksumme filen på en annan disk. Och uppdatera den filen så fort du kopierat nya filer. etc etc Ett jävla jobb.

Eller, så använder du ZFS som gör allt detta ovanstående helt automatiskt åt dig. Du har ett mjukvarurraid, och ZFS gör SHA256 checksummor på alla filer och jämför och om någon minsta bit har ändrat sig, så tar ZFS fram en kopia och reparerar allting och informerar dig. Dessuotm kan du använda "snapshots" som skyddar mot t.ex. oavsitklig radering och mot virus.

ZFS är mycket säkrare än hårdvaru raid kort., och det är gratis. Stora lagringsservrar som lagrar PetaByte och kostar miljoner använder ZFS. Testa att ladda ned FreeNAS eller FreeBSD eller Solaris och labba lite i VirtualBox så slipper du installera dessa OS. Det går att köra ZFS på Linux också.

ZFS är en barnlek, jag har kört FreeNAS på en ESXi server med full fräs över gigabit. Inga konstigheter, inte haft några prestandaproblem även fast jag kört diskarna som vmdk istället för RDM.

ZFS på linux är absolut inte komplicerat, jag tycker det är enklare att sätta upp det på ubuntu än på freenas. Men det är väl mest för att jag tycker att gui't är rörigt.
4 rader i terminalen är allt som behövs i ubuntu.
add-apt-repository ppa:zfs-native/stable
apt-get update
apt-get install ubuntu-zfs
zpool create warezdump raidz1 sdb sdc sdd sde

så har du skapat en motsvarande raid5, inget mer trixande behövs om man inte vill.
Poolen monteras automagiskt vid boot i /warezdump

Själv kör jag en raidz2 på 7st 2tb diskar utan att gjort mer än jag skrev ovan.
Har en i3-2100T (slöaste i3 proppen) med 8gb minne.

root@NASDISK:~# dd if=/dev/zero of=/nasdisk/zerofile.000 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 36.046 s, 291 MB/s

root@NASDISK:~# dd if=/nasdisk/zerofile.000 of=/dev/null bs=1M
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 32.6235 s, 321 MB/s

Inget problem med extra lager om man kör passthrough till SAS/SATA-kontrollern.

Jo det blir ett extra lager och det var just anledningen till att jag testade det för jag villle se hur mycket sämre prestanda det var.
Men det var bara marginell skillnad när de låg i en VMDK, så det är absolut inget problem att ha det liggandes så.

Notetera att jag inte kör det i ESXi hemma, där rullar det på Ubuntu och även där min stats. kommer ifrån.

Jo visst är VMFS ett tilll lager, jag skulle aldrig köra zfs i en vmdk, men det var ju bara för att jag ville testa prestandan.

Snälla, bit rot är inte ett reellt problem för de flesta, det är inte farligt att lagra data på andra filsystem eller att använda hårdvaruraid. Jag och många andra gör det dagligen, i stora produktionsmiljöer med många TB data. ZFS fungerar säkert jättebra för dig, men du beter dig lite som kyrkan förr i tiden och försöker skrämma till dig anhängare. Sluta med det, du framstår bara som en fåne som inte har någon som helst aning om vad han pratar om.

Bit rot är inte ett problem med lite data, när du har några TB data så får du inte så ofta bit rot. I snitt 4 sektorer på en 2TB disk har bit rot. Men när du har mycket data, så blir bit rot ett reellt problem.

T.ex. Amazon skriver att de ser data corruption precis hela tiden.
http://www.zdnet.com/blog/storage/data-corruption-at-massive-...
-Hardware, software and firmware all introduce errors. ". . . absolutely nobody and nothing can be trusted."
-More error detection is always better. Every time he's added more he's been ". . . amazed at the frequency the error correction code fired."
-Corruption is everywhere. In one case he found latent data corruption on customer disks that was so bad that customers thought the software was buggy while the real problem was on-disk.
-You absolutely need ECC on servers. And, he concludes ". . . ECC memory should be part of all client systems."
Another example. In this case, a fleet of tens of thousands of servers was instrumented to monitor how frequently the DRAM ECC was correcting. Over the course of several months, the result was somewhere between amazing and frightening. ECC is firing constantly.

Så visst, när du administrerar små servrar så får du garanterat bit rot. Men de sektorerna är få. Med mycket data så har du alltid bitrot och behöver checksummor på allt för att fånga bit rot. Det är bara att läsa på senaste forskningen och vad folk som driftar stora system säger, t.ex. CERN. CERN lagrar så mycket data att bitröta är ett seriöst problem för dem, och de går nu över till ZFS. IBMs nya superdator SEQUIOA som ska lagra 55 PetaByte data kör Lustre ovanpå ZFS numera, istället för ext3.

Om du också skulle läsa på senaste forskningen och vad folk som lagrar MYCKET data berättar, så skulle du också ta dig en funderare. Du kanske borde googla runt lite på "data corruption"? Du kanske ändrar inställning på kuppen.

Har du någonsin märkt att ECC RAM i dina servrar rapporterar att de råkat ut för bitfel i RAM? Sånt händer hela tiden i RAM. Om du inte märkt det, så betyder det inte att du haft tur - det betyder bara att du inte förstått det. T.ex. en server som beter sig märkligt, ett program som kraschar, en fil som blir korrupt etc - mycket sånt kan elimineras om man skyddar sig mot bitröta. MS samlar data efter Windows krascher, och upptäckte att 30% av alla Windows krascher beror på bitfel i RAM - så man skulle kunna få mycket färre Windows krascher om man har ECC RAM.

Framförallt, hårdvaruraid är notoriskt opålitiliga när det gäller data corruption och bör undvikas om man tycker att ens data är viktiga.

Om ens data är viktiga, så SKA man använda ECC RAM, och ett filsystem som gör MD5 checksummor på precis allting, vid varje läsning. ZFS gör detta (SHA256 checksummor). Om man tror att ECC RAM inte är viktigt, eller att MD5 checksummor inte är viktigt, så borde man läsa på lite. Börja med att läsa på om Big Data och Data corruption. Och framförallt, undvik hårdvaruraid.

Att ta upp ECC-minnen i diskussionen är ju bara fånigt, det är ett faktum att bitfel i minnet händer och att det händer ofta. Vad du däremot inte lyckas precisera är hur vanligt det är med bitröta på lagringssystem som inte är Amazon, CERN eller liknande. Hur är detta relevant i samanhanget?

På vilket sätt är hårdvaruraid notoriskt opålitliga när det gäller datakorruption, och varför bör de undvikas om man tycker att ens data är viktiga?

Man ser bitröta lättast på stora datamängder. Skälet till det är att diskar har genom decennierna blivit snabbare och större, men de har inte blivit säkrare.

En typisk högkvalitets server Enterprise SAS säger i sina spec sheet från tillverkaren att för varje 10^16 bitar man läser, så får man i snitt ett fel som diskens felkorrigeringskoder inte kan korrigera:
http://www.komplett.se/k/ki.aspx?sku=759326#extra
"Oåterkalleligt fel 1 per 10^16"

Men ett fel per 10^16 bitar är inte så farligt, om det vore så väl. Problemet är att det finns massa andra felkällor än disken själv. T.ex. höga ljud stör disken, det räcker att du skriker högt bredvid disken så skakar den till och får problem att läsa/skriva:
http://www.youtube.com/watch?v=tDacjrSCeq4

Kosmisk strålning, solutbrott är ett STORT problem. Faktum är att Intel ville bygga in detektorer i cpun och när det blir kosmisk strålning så ska cpun spela om alla uträkningar, etc.

Poängen är att alla felkällor ger massa datakorruption, mycket mer än 1 per 10^16. T.ex. NetApp som gör stora lagringsservrar för många miljoner kr, har gjort en undersökning i praktiken. Bland 1.5 miljoner hårddiskar från kunder så:
http://en.wikipedia.org/wiki/ZFS#Data_Integrity
"A real life study of 1.5 million HDDs in the NetApp database found that on average 1 in 90 SATA drives will have silent corruption which is not caught by hardware RAID verification process; for a RAID-5 system that works out to one undetected error for every 67 TB of data read.[27]"

En annan källa säger att på varje 2TB disk så finns i snitt fyra sektorer med datakorruption, men denna har jag inga källor för, så denna uppgift är inte tillförlitlig.

Sammanfattning; det är liten chans att få datakorruption, typ som att vinna på lotto. Men om du köper tillräckligt många biljetter så kommer du garanterat vinna. Och om du har enorma mängder data, så kommer du se datakorruption hela tiden. Vilket CERN och Amazon och NetApp rapporterar - de har alla stora mängder data. Det är bara att läsa länkarna om du tror att jag hittar på.

Om du har några små servrar med kanske 10TB data så är risken för datakorruption liten. Om du köper 10,000 lottobiljetter så är chansen liten att du vinner. Men om du köper 1000.000.000.000 stycken lotter, så kommer du vinna flera gånger.

Därför att hårdvaruraid inte är designade att fånga upp datakorruption. De gör parity beräkningar, dvs XOR beräkningar för att man splittat data mellan olika diskar och ska sammanställa alla data igen. Men de gör inte checksummeberäkningar i syfte att fånga datakorruption. Du bör göra en typ MD5 checksumma på allt du läser och skriver hela tiden - då är du säker. Hårdvaruraid gör inte det. Sen finns det andra problem med hårdvaruraid som du säkert känner till, t.ex write-hole error som alla hårdvaruraid lider av (ZFS är immun mot detta problem).
http://en.wikipedia.org/wiki/RAID#Problems_with_RAID

Men ZFS gör checksummeberäkningar, det gör SHA256 checksummor på allt, precis hela tiden. Därför kräver ZFS mer cpukraft än vanliga filsystem, som aldrig gör MD5 checksummor. Att göra MD5 checksummor tar ju massa tid, och då blir allt långsammare. Tänk själv, om du gjorde MD5 på precis alla filer hela tiden, skulle det inte gå långsamt då? Då uppnår man iofs stor säkerhet, men tappar prestanda. Vad är viktigast? Att det går snabbt och lite datakorruption då och då, eller långsamt och säkrade data?

Sen finns det även forskning som visar att ZFS är säkert, medan NTFS är inte säkert. Forskaren pratar om NTFS, ext3, XFS, JFS, etc:
http://www.zdnet.com/blog/storage/how-microsoft-puts-your-dat...

Så om du hanterar mycket viktiga företagsdata, så bör du köra MD5 checksummor på precis alla filer, en gång om dagen i alla fall. Och sen bör du jämföra alla checksummor för att se om de har ändrats. Så du måste spara alla checksummorna i en fil och uppdatera filen hela tiden när något ändrats. Och om en fil korruptas, så måste du ersätta med en frisk kopia. Eller så använder du ZFS, som gör allt detta helt automatiskt åt dig.

Microsoft gjorde en studie, de samlar ju alla kraschdata från Windows. MS kom fram till att 20-30% av alla krascher berodde på bitröta i RAM. Mao, om man hade ECC RAM så skulle man sluppit 20-30% av alla krascher. Det är väldigt ofta, detta.

Bra hjärna du har! Det är exakt det som forskarna kom fram till när de undersökte olika filsystem. De injicerade olika artificiella fel i olika filsystem och såg hur väl filsystemen hanterade problemen: inte alls. Men ZFS ensamt klarade av att hantera alla problemen:
http://research.cs.wisc.edu/wind/Publications/zfs-corruption-...

Dock, kom fram forskarna fram till att om de injicerade fel i RAM så klarade inte ZFS av att märka felen längre. ZFS sparar ned korrekt på disk, vad den får. Om den får skit (pga fel i RAM) så sparar den skit. Visst blir skiten korrekt sparad (vilket man inte kan säga om andra filsystemen som flippar bitar randomly och datakorruption) men för att det ska vara någon poäng med ZFS, så rekommenderade forskarna att man ska köra ECC RAM och ZFS. Precis din slutsats, utan att lägga ned månader av forskning.

Jag håller inte med ditt resonemang.

Antag att du har ETT enda paket, en Windows uppgradering på 100MB som ska skickas ut till alla datorer på företaget. Nu säger du att eftersom den skickas ut så många gånger, så blir det totalt 40TB data som skickas ut. Och om du kör checksummor på 40TB data så borde du se ett fel, men det ser du inte. Alltså är inte bitröta på diskar ett problem! Eller?

Men jag håller inte med om detta resonemang. Därför att:
Du har ett enda paket, som tar upp 100MB. Det ligger på disken. Hur stor är risken att du får bitröta på just dessa 100MB? Mycket liten. Sen skickas detta paket ut till alla servrar som sparar ned filen på disk och direkt installerar och sen kastas paketet. Hur stor är risken att du får bitröta på servrarna under den korta tiden? Mycket liten. Hur stor är risken att du får bitröta på just era paket? Mycket liten. Hur många paket har ni? 800st, och varje tar 100MB, så det blir totalt 80 GB data. Det är inte mycket data det. Det är inte ens en tiondels TB.

Återigen, om man har lite data så är inte risken så stor för bitröta. Men när man lagrar STORA mängder data, så är bitröta och annan datakorruption ett mycket stort problem.

Men det är helt korrekt att göra checksummor på paketen som ni gör. Helst bör man ju göra checksummor på ALLA filer. Ha ett program som ligger och kör MD5 checksummor i bakgrunden hela tiden (som t.ex. ZFS gör).

Och glöm inte att göra MD5 checksummor på originalfilen och kopian i molnet. Ibland när jag laddar ned ISO filer så funkar inte den, så får jag ladda ned ISO filen igen. Dvs, data korruption. Nånstans.

MD5 checksummor är viktiga om man är noga med sina data.

Nej, använd en algoritm som fungerar istället. MD5 är dokumenterat trasig sedan åtminstone 2005. Är man riktigt paranoid eller extremt trygghetsberoende skulle man antagligen hävda att MD5 blev persona-non-grata från 1996.

Ok tack för informationen! Vet du om SHA256 oxå har brister? ZFS har ju flera olika checksummealgoritmer förutom SHA256, men SHA256 är ju bäst av dem. Själv kör jag inte SHA256 checksummealgoritmen på min ZFS burk, eftersom jag inte ens har ECC RAM. Men när jag skaffar supermicro moderkort + Xeon + ECC + ZFS så får jag en mycket säker lösning. Då ska jag även slå på SHA256.

Ok, då förstår jag. Det är ju bra att ni inte detekterat checksummefel på era paket diskarna nån gång.

En fråga, har ni någonsin detekterat ECC checksummefel? Som bl.a. Googles stora undersökning visar så fick de ECC checksummefel ganska ofta bland alla sina 100.000 tals servrar. Ni borde fått ECC checksummefel nån gång, och om ni inte nånsin sett ECC fel, så har ni haft tur, eller så har ni gjort fel nånstans. Om ni aldrig sett ECC fel, så kanske ni heller aldrig sett disk checksummefel heller. De kanske hänger ihop på nåt sätt?

Poängen är i alla fall att vi pratar ren statistik och sannolikheter. Bara för att ni inte sett några checksummefel så betyder det inte att ni är immuna. Eller så har ni haft tur. Eller så betyder det att ni vet exakt vad ni gör hur man för att motverka datakorruption. Vi kan i alla fall konstatera att ECC fel inträffar ofta, men diskar har massa rörliga delar och är långt känsligare så rimligtvis borde det inträffa datakorruption även på diskar. Brukar det stå i RAM spec sheet "1 fel per.... X lästa bitar"? Nej det gör det väl inte? Men det gör det i diskar, även hos mycket dyra high end Fibre Channel diskar, så det blir alltså mer fel bland diskar, än bland RAM. Och bland RAM blir det ofta fel, så då kanske det blir ännu mer fel bland diskar.

Vi pratar statistik och man kan inte uttala sig med visshet. Jag känner många personer, men har aldrig träffat någon som vunnit stort på lotto. Det betyder ingenting, inga slutsatser kan dras från det.

Poängen är att datakorruption bland diskar är ett reellt problem. Och folk får själva bedöma hur viktigt de tycker detta är. De som lagrar stora mängder data, ser datakorruption hela tiden. Detta är konstaterade fakta, det är bara att läsa länkarna från Amazon, CERN, NetApp, etc. Nu vet ni i alla fall om att problemet med datakorruption existerar, och det är upp till er hur ni vill hantera det. Ni kan köra utan ECC RAMkretsar på era servrar om ni vill, men det rekommenderas inte. Men ni kanske har tur och slipper ECC fel? Men även om ni inte får ECC fel, så är det väl onödigt att fresta på turen, och istället alltid köra ECC på era servrar. Vilket jag förutsätter att ni gör, för ni kör väl ECC på era servrar?

På samma sätt, om 10 år, så gissar jag att det rekommenderas att man bör köra lagringslösningar där det görs checksummor på precis allt, hela tiden. ECC RAM var inte ett stort problem förrut, men idag känner folk till det och fler och fler kör ECC, även hemanvändare. Är det dåligt att göra checksummor på allt, hela tiden? Bör man rekommendera emot såna lösningar?

Mer läsning och forskningsartiklar om datakorruption finns här, för den som är intresserad av ämnet:
http://en.wikipedia.org/wiki/Data_corruption
http://en.wikipedia.org/wiki/Soft_error
http://en.wikipedia.org/wiki/Cosmic_ray#Effect_on_electronics
http://en.wikipedia.org/wiki/ZFS#Data_Integrity

Jag tror det är mer minnesstrul idag än förr. Idag är man nere på typ 22nm och det är väldigt tunt och känsligt. Förr körde man på 135nm och det är inte alls lika känsligt. Dessutom har vi 16B kapslar idag, och allt är tätt packat och gissningsvis, mer känsligt

Det här är ett STORT problem för seriösa datortillverkare. T.ex. IBMs stordatorer kan spela tillbacka instruktioner om det är fel nånstans. Detsamma med vissa SPARC cpuer. Det du pratar om, kallas RAS (reliability, avaliability and servicebility) typ, hög upptid. Och det är RAS som Enterprise företag vill åt och är eftertraktat, inte prestanda. Och det är RAS som kostar mycket pengar. När man tittar på en svindyr Unix server, så är det RAS man betalar för. Inte prestanda. Nu råkar en del av de servrrarna vara snabba också, t.ex. IBMs P595 unix server som användes för det gamla TPC-C rekordet kostade 35miljoner USD, listpris. Det blir typ en kvarts miljard. För en enda server.

Om vi istället tittar på IBMs stordatorer som är dyra på riktigt, och inte alls något billigt Unix skit, så har Stordatorerna mycket långsammare cpuer än en vanlig high end x86 cpu, även den senaste cpun på 5.3GHz med ~200MB cpu cache är långsammare än en vanlig high end x86 cpu. Men Mainframes har extremt god RAS, viktiga komponenter är dubblade och kanske även tripplade. Har för mig att t.ex. beräkningar utförs tre i taget av tre cpuer, och om nån visar fel så stängs cpun av, och ett larm går. Allt detta kostar multum att utveckla. Då blir prestanda lidande. Prestanda är sekundärt. Vad är viktigast, att det går snabbt och siffror blir fel (tänk bank) och krascher ibland, eller att allt är korrekt men lite långsammare? När du kommit upp till en viss nivå så räcker prestandan och du behöver inget snabbare.

Detsamma med ZFS: checksummor på allt som drar ned prestandan men allt blir säkrare - eller vinna benchmarks och korrupta data? Jag börjar faktiskt prioritera RAS mer och mer, än prestanda. Förrut, innan jag började jobba, så var prestanda viktigast. Numera är det RAS, nästan. Annars skulle jag skita i ZFS och bara köra nåt snabbt filsystem, som inte gör ordentliga fsck kontroller och fuskar rent allmänt, som linux hackern Ted Tso förklarade. Han skapade ext4, och sade att Linux folk ofta fuskar och stänger av felkontroller och sånt, bara för att vinna benchmarks. T.ex. ville Ted Tso slå på nån säkerhetsgrej "write barrier" eller nåt sånt i ext3, men Linux hackern Andrew Morton förbjöd det, eftersom "datakorruptionen som kunde bli följden var sällsynt och det var viktigare att vinna benchmarks"!!!! Man kanske förstår varför det finns sysadmins som vägrar jobba med Linux, eller Windows. Här är lite mer info om Linux fusk:
http://milek.blogspot.se/2010/12/linux-osync-and-write-barrie...