Skrivet av Hieronymus Bosch:
Åh, men det beror på vilken raidimplementation som används. Om raidkontrollern har batteribackup kommer den halva transaktion som inte hann ned till disk att sparas i minnet tills hårddiskarna är tillgängliga igen. Oavsett anledning till att data inte hann skrivas.
Angående Write Hole error som alla hårdvaruraid lider av, om du använder batteribackup så skyddar du datat i hårdvaruraidets cache, ja. Men du skyddar inte datat i hårddiskarnas cache. Så batteribackup räcker inte (ZFS är immunt mot detta problem) eftersom det inte skyddar mot write-hole-error som alla hårdvaruraid lider av.
http://www.raid-recovery-guide.com/raid5-write-hole.aspx
Skrivet av Hieronymus Bosch:
ZFS har ingen möjlighet att misstro exempelvis en SSD som hävdar att en skrivning hamnat på icke-flyktig lagring, trots att den fortfarande ligger i diskens skrivkö och därmed kommer att gå förlorad vid strömbortfall.
Sant är att ZFS inte upptäcker brister i all underliggande hårdvara. T.ex. om du använder trasig CPU, eller trasigt RAM så får ZFS problem. Men det är inte heller ZFS uppgift att kontrollera CPUns alla beräkningar, eller om RAM har gått sönder, etc. Man kan inte begära av ZFS att upptäcka och hantera en felaktig CPU eftersom ZFS är ett filsystem. Däremot kan man begära att ZFS ska upptäcka och korrekt hantera alla fel i lagringen - vilket ZFS gör korrekt. Om SATA kabeln är lös, buggar i disk firmware, etc - allt detta upptäcks och hanteras korrekt.
https://en.wikipedia.org/wiki/ZFS#Data_integrity
ZFS skyddar bla mot "...phantom writes (the previous write did not make it to disk), misdirected reads/writes (the disk accesses the wrong block), DMA parity errors between the array and server memory or from the driver (since the checksum validates data inside the array), driver errors (data winds up in the wrong buffer inside the kernel), accidental overwrites (such as swapping to a live file system)"
Så ZFS upptäcker alla fel och brister i underliggande lagringshårdvaran enligt den forskningsrapporten du länkade till och citerade ifrån. Men ZFS upptäcker inte fel och brister i CPUn eller RAM eller grafikkortet eller ljudkortet eller nåt annat som inte har med lagringen att göra. Och det ska det inte heller.
Din forskningsartikel du länkar till skriver att ZFS upptäcker alla fel på disken, men hanterar inte fel i RAM väl. Varför stanna där? Varför tar inte forskningsartikeln upp att ZFS inte hanterar fel i CPU väl heller? Eller i grafikkortet? etc? Nej, alla dessa fel är inte ett filsystems ansvarsområde. Din forskningsartikel säger att ZFS upptäcker alla fel på diskarna och dessutom korrigerar alla fel på diskarna om man kör med redundans. Forskningsartikeln gör alla experiment på en singel disk, och det är självklart att om man förstör ett visst data på en singel disk fullständigt så kan inte ZFS reparera datat. Artiklen säger även att om de kört ZFS med redundans, mirror eller raid, så skulle ZFS detekterat felet och korrekt tagit fram datat från en annan disk. Men nu gick det inte, eftersom de körde singel disk. Sen börjar de undersöka fel i RAM och då är det fel som ZFS inte kan hantera, likväl som fel i CPU, etc. Så de har fel om de kräver att ett filsystem ska hantera fel i RAM och CPU och grafikkort, etc. Forskarnas rekommendation är att använda ECC RAM för att eliminera fel i RAM. Men varför stanna där? Varför inte rekommendera att använda tre cpuer som alla gör samma beräkningar och ifall en cpus beräkningar diffar, så stängs den cpun av? Låter detta vettigt? Och dessutom, alla andra filsystem har också problem om RAM är trasigt eller CPUn är trasig, etc.
"We run ZFS on top of a single disk for our experiments....In summary, ZFS successfully detects all corruptions and recovers from them as long as one correct copy exists. The in-memory caching and periodic flushing of metadata on transaction commits help ZFS recover from serious disk corruptions affecting all copies of metadata. For user data, ZFS does not keep redundant copies and is unable to recover from corruptions [NÄR MAN KÖR SINGEL DISK, MEN ÅTERSKAPAR ALLA DATA KORREKT NÄR MAN KÖR RAID/MIRROR]. ZFS, however, detects the corruptions and reports an error to the user."
Om du har trasigt RAM, så kommer kanske ZFS skriva sönder datat, ja, eftersom checksummorna diffar i det trasiga RAMet mot disken. Men detta kräver att checksumman beräknas på just den trasiga RAM stickan, vilket kanske är osannolikt. Men, det viktiga är att just detta fel med trasigt RAM kommer upptäckas snabbt, eftersom när ZFS börjar skriva ned trasigt data över hela disken så kommer checksummorna diffa. Eftersom RAM är trasigt så kommer beräkningarna inte ge samma resultat varje gång, de kommer diffa hela tiden. Ena gången kanske checksumman blir 12345 och nästa gång blir checksumman 23510 men de borde vara samma checksumma. Och så fort checksummorna diffar så kommer omedelbart användaren få reda på det mha "zpool status". Så trasigt RAM kan man märka snabbt och vidta åtgärder.
Vad tror du händer om ett normalt filsystem har trasigt RAM? Eller ett hårdvaruraid kort? Ja de kommer fortsätta skriva sönder data i det dolda utan att du märker nåt eftersom de inte har checksummor för dataintegritet.
Skrivet av Hieronymus Bosch:
Så du vidhåller att filsystem växer automatiskt, efter behov? Och FreeNAS kan använda ZFS-volymer för iSCSI, så innehållet i din parentes är felaktigt.
Och ja, filsystem växer automatiskt efter behov. Jag fattar inte din fråga. Missförstår vi varandra? Det är ungefär som att du frågar om en katalog växer ju mer filer du stoppar däri. När du gör "zfs create tank/mittFilsystem" så växer filsystemet efter behov, den beter sig som en katalog.
ZFS volymer används främst för iSCSI, och ingen normal användare har behov av det. iSCSI används främst på stora SAN servrar. Har du något normalt use case för iSCSI för en hemanvändare?
Skrivet av Hieronymus Bosch:
Rapporten säger att ZFS inte hanterar de fel på disk som man rimligtvis inte kan kräva att den ska överleva:
Fel igen. Rapporten använder en singeldisk och ZFS skulle fixat alla fel om forskarna använt redundans såsom mirror/raid.
Skrivet av Hieronymus Bosch:
Så ZFS är inte immunt mot fel i underliggande hårdvara. ZFS gör inte checksummekontroller på data i minne -- det här är troligtvis en tradeoff där man förlitar sig på ECC-minnen eller servrar med stöd för speglat minne.
ZFS är immunt mot fel i underliggande hårdvara som rör lagringen. ZFS kan inte hantera fel i cpun eller i grafikkortet, men det är inte heller ett filsystems uppgift. Jag kanske borde tillägga att ZFS inte är magiskt och du kan inte kräva att ett filsystem ska fixa fel i CPUn eller minnet. Och Ja, man kan faktiskt förlora data även med ZFS - inget system är 100% säkert.
Skrivet av Hieronymus Bosch:
Länk? Jag hittar bara en rapport om behovet av dataskydd och olika sätt att uppnå detta. ZFS nämns inte. Extra intressant är att CERN valde att bygga ett eget lagringssystem för sin största lagring.
Dock råkar jag veta att ZFS används inom CERN. Hur? Jo, deras interna IT-drift har en publik wiki med ärenden och för några år sedan drabbades en av deras ZFS-baserade lagringslösningar av dataförlust.
Som berodde på ett underliggande hårdvarufel.
Som ZFS inte skyddade mot.
Här är länk från CERN som visar att det räcker inte med lite checksummor, det måste göras på rätt sätt och att det bara är ZFS som de tycker har rätt approach:
https://indico.desy.de/getFile.py/access?contribId=65&session...
sid 10:
"data corruption happens with expensive ECC-memory too"
sid 24:
"Silent corruptions are a fact of life"
"Elimination of silent corruption seems impossible"
sid 23:
"Checksumming? -> not necessarily enough"
"end-to-end checksumming (ZFS has a point)"
Jag vet att CERN använt ZFS för lagring förrut i alla fall för tier-2 och tier-3, dvs all långtidsslagring där datat ska analyseras i lugn och ro. Jag vet även att tier-1 dvs, där datat produceras, sker på Linux burkar med vanliga filsystem. Men allt data strömmas direkt till tier-2 och tier-3 sajter för närmare bearbetning. Så det kan vara så att din länk rör tier-1 och inte långtidsslagringen, som lagras på ZFS (alla fall förrut). Vid närmre eftertanke är det viktigt att långtidslagra på en säker lösning eftersom allt eftersom tiden går så introduceras datafel. Men precis när datat producerats är det inte lika viktigt, bara det strömmas iväg och backuppas säkert omedelbart.
https://blogs.oracle.com/simons/entry/hpc_consortium_big_scie...
"Having conducted testing and analysis of ZFS, it is felt that the combination of ZFS and Solaris solves the critical data integrity issues that have been seen with other approaches. [CERN] feel the problem has been solved completely with the use of this technology. There is currently about one Petabyte of Thumper [ZFS server] storage deployed across Tier1 and Tier2 sites. That number is expected to rise to approximately four Petabytes by the end of this summer."
Sen kan det hända att man förlorar data även med ZFS, inget system är helt 100% säkert. Men CERN anser (ansåg?) att det är ZFS som gäller. Skälet är att ZFS använder end-to-end checksumming. Och det gör inga vanliga system, som t.ex hårdvaruraid.
End-to-end checksumming är det som är unikt för ZFS och därför är ZFS så säkert. Det betyder att datat i ena änden (på disken) jämförs med datat i andra änden (i RAM) med checksummor. Och då hittar du fel som du bara kan hitta när du jämför i båda ändarna. Detta gör inte hårdvaruraid. Om du lekt viskleken någon gång så viskar man ett ord i örat och nästa person viskar samma ord vidare, och på slutet så har ordet ändrats jättemycket, eftersom det blir fel mellan varje person.
Så antag att du har checksummor i varje lager i lagringsstacken, t.ex. checksummor på disken, och antag att raidkortet har checksummor, etc hela vägen upp till RAM. Men om du aldrig jämför checksummorna när du byter nivå så kan de förvanskas. Enda sättet att få lagring helt säkert är att jämföra checksummorna i båda ändarna - vilket ZFS gör. Och det kan ZFS göra pga att ZFS är kombinerat filsystem, raid, volymhanterare, etc allt i ett. Så ZFS har kontroll över hela stacken och kan alltid jämföra datat medan datat byter nivå i stacken, från disk till raid, etc. Och du istället jämför t.ex. vanliga filsystem på Linux/Windows - så är filsystemet separerat från raidet som är separerat från volymhanteraren, etc - så ingen kontroll görs att datat är korrekt i båda ändarna av lagringsstacken. Och det är därför det blir fel på vanliga filsystem.
ZFS jämför alltid alla data i båda ändarna. Det är det CERN menar när de skriver att "checksumming is not enough - you need end-to-end checksumming like ZFS do". Att bara lägga till checksummor i ett lager räcker inte, det blir massa fel när datat byter nivå i stacken. T.ex. har hårddiskar massa checksummor för att detektera fel i lagringen, men du kan ändå råka ut för bitröta och andra fel. Varför? För att end-to-end checksummor inte sker.
https://en.wikipedia.org/wiki/Hard_disk_drive#ERRORRATESHANDL...
Och så länge du använder separat filsystem, och separat raid, etc - så kommer du få fel. Så BTRFS är därför också liknande uppbyggt som ZFS, med monolitiskt allt-i-ett. Och då kan BTRFS göra end-to-end checksummor - men jag inte sett forskning på hur bra BTRFS gör det. Bara för två dagar sen fick Phoronix.com ett produktionsfel med BTRFS, läs kommentarerna i tråden:
http://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Syst...
Så kort sagt, en lösning med separat filsystem och separat raidkort, etc - kan aldrig ha end-to-end checksummor. Och just därför är det aldrig lika säkert som ZFS. Så lägg ned hårdvaruraid. Du måste ha en monolitisk allt-i-ett lagringssystem, enligt CERN.
https://en.wikipedia.org/wiki/Data_corruption#SILENT
"a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected by the hardware RAID controller"
