Saddam och Weeblie spekulerar om filsystem

Permalänk
Medlem

Saddam och Weeblie spekulerar om filsystem

Denna tråd är utbruten ur denna, så om originalinlägg till citat saknas eller liknande kan det löna sig att titta där.

Citat:

Ursprungligen inskrivet av saddam
Men om filsystemet kraschar så blir du av med allt du sparat även under flera år.

Det är då ens eget fel att man inte har någon form av periodisk backup på allt ens arbete, helst off-site sådan för att även täcka brand och stöld.

RAID, vare sig det gäller klassisk RAID-1/RAID-5/RAID-6 eller RAID-Z, är endast till för att öka upptiden på ens server och inte ett alternativ till backup.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Det är då ens eget fel att man inte har någon form av periodisk backup på allt ens arbete, helst off-site sådan för att även täcka brand och stöld.

RAID, vare sig det gäller klassisk RAID-1/RAID-5/RAID-6 eller RAID-Z, är endast till för att öka upptiden på ens server och inte ett alternativ till backup.

Absolut. Jag håller med dig till 100%. Du säger vettiga saker.

Men det är inte många hemanvändare som back uppar sin filserver, misstänker jag? Jag gör det inte. 8st 1TB diskar i raidz2 får räcka för mig som säkerhet. Att fixa en backuplösning för 6TB skulle vara för meckigt och dyrt, tror jag. Senare kommer jag byta mina 1TB diskar mot 2TB diskar. Då måste jag back uppa 12TB nånstans. Det vet jag inte hur jag ska fixa på ett enkelt och smidigt sätt. Vill inte ha en till dator hemma.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Det är så väldigt komiskt att detta sker, trots allt prisande av ZFS och dess dataintegritetskontroller. Är det inte längre meningen att ZFS ska ge full end-to-end skydd, oavsett om man kör med state-of-the-art själv-reparerande hårdvara eller budget-varianter med halvrisiga firmwares?

Möjligt. Men som de skriver i den tråden:

"It is quite simple -- ZFS sent the flush command and VirtualBox
ignored it."

"consumer grade hardware is reporting to ZFS that writes have succeeded, when in fact they are still in the cache."

Jag tror det blir ganska svårt att fixa till detta? ZFS begär något, och får en rapport om att "det är klart nu" men det är inte alls klart.

Jag har berättat om detta problem tidigare i OpenSolaris tråden. Jag skrev att det händer att ZFS får problem, därför att billig hårdvara inte alltid följer standarder. Hårdvarutillverkarna försöker få ned priset genom att inte följa standarder.

Citat:

Ursprungligen inskrivet av Weeblie
Att skylla på att ZFS bli "lurad" av VB är som att skylla på att bit-röta sker eftersom RAID-5 blir "lurad" av S.M.A.R.T.

Jag håller inte med dig om denna liknelse.

Så du menar att SMART rapporterar falskeligen att allting är bra, men i själva verket så har alla larm gått och tutar för fullt och disken håller på att krascha? Och då blir RAID-5 lurad eftersom den litar på SMART och inte vidtar åtgärder?

För det andra, SMART är inte alls tillförlitligt och inget att lita på. Google(?) gjorde en stor undersökning på massor av diskar och slutsatsen var att SMART är skräp. Den säger ingenting. Du verkar mena att RAID-5 vidtar åtgärder beroende på vad SMART säger. Annars gör RAID-5 ingenting. Men SMART är skräp och det är lika bra att anlita en spåkärring som gissar. Varför ska man lita på en spåkärring?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Jag håller inte med dig om denna liknelse.

Så du menar att SMART rapporterar falskeligen att allting är bra, men i själva verket så har alla larm gått och tutar för fullt och disken håller på att krascha? Och då blir RAID-5 lurad eftersom den litar på SMART och inte vidtar åtgärder?

Moderna diskar skyddas av både felkorrigeringskoder och checksummor.
Dataöverföring via S-ATA kabeln skyddas av checksummor.
PCI-Express gränsnittet skyddas av checksummor.

Cache-minnena som används i varje led har felkorrigeringskoder (åtminstonde på serverhårdvara).

Bit-röta, d.v.s. fel som inte bara är okorrigerbara men också odetekterbara, bör därför hårdvarumässigt vara en (i princip) omöjlighet.

Var ligger då oftast problemet hos dem som har drabbats av det? Jo, på mjukvaran. ZFS's checksummor är främst tänkt att skydda mot firmware-buggar och det är just där ZFS har misslyckats här.

Citat:

Ursprungligen inskrivet av saddam
För det andra, SMART är inte alls tillförlitligt och inget att lita på. Google(?) gjorde en stor undersökning på massor av diskar och slutsatsen var att SMART är skräp. Den säger ingenting.

Googles undersökning säger inte emot det jag har skrivit. S.M.A.R.T.'s ursprungliga huvudsyfta är att förutsäga när en disk håller på att dö, vilket den av erfarenhet och Googles undersökning visar sig vara långt ifrån idiotsäker (enbart runt hälften av fallen upptäcks i tid).

Men disken kan/ska också rapportera när en sektor läses in och triggar felkorrigeringskoden alternativt checksumman; d.v.s. kombinerat med RAID så ska man ha ett fullt tillräckligt skydd utan att behöva ta in ZFS.

Citat:

Ursprungligen inskrivet av saddam
Du verkar mena att RAID-5 vidtar åtgärder beroende på vad SMART säger. Annars gör RAID-5 ingenting. Men SMART är skräp och det är lika bra att anlita en spåkärring som gissar. Varför ska man lita på en spåkärring?

Jag förstår inte ditt resonemang här.

När ZFS får problem så skyller man på billig hårdvara som inte följer standarder, trots allt prisande om att man inte behöver ta till dyra diskar och dyra disk-kontrollers när man använder sig av ZFS.

När "klassisk" RAID-5/6 får problem så skyller man på RAID-5/6 och inte diskarna som inte rapporterar dem fel de kan göra.

ps. Det är värt att notera här att när ZFS dör så har den en tendens att dö katastrofalt, troligen p.g.a. av komplexiteten på filsystemet. "Klassisk" RAID-5/6, även mjukvarubaserad sådan, kombinerat med ett enkelt filsystem som UFS verkar vara mer robust när olyckan väl är framme.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Bit-röta, d.v.s. fel som inte bara är okorrigerbara men också odetekterbara, bör därför hårdvarumässigt vara en (i princip) omöjlighet.

Jag förstår inte hur du drog denna slutsats. Kan du förklara en gång till? Tankesprånget du gjorde, var lite för stort för mig.

Du har inte läst CERNs undersökning som visade att de hade fel i sina filer, utan att disken, eller raidet eller någon annan hårdvara rapporterade att det var fel? CERN skrev ett förutbestämt bit mönster på Linux hårdvaruraid. Efter några veckor, så skannades alla filer igenom och CERN tittade på om någon fil avvek från det bestämda bitmönstret. CERN hittade 500 avvikelser på 100 hårdvaruraid, det var alltså fel, dvs bitröta. Hårdvaran upptäckte inte dessa fel, och hur ska hårdvaran kunna korrigera dessa fel om den inte ens känner till felen? Men du menar att dessa fel "bör vara hårdvarumässigt en omöjlighet"? Det bör inte kunna inträffa, det räcker att skydda sig med hårdvaruraid, som CERN gjorde? CERN tycker uppenbarligen inte som du. CERN håller faktiskt på att implementera ZFS nu, på Solaris. CERN är inte nöjda med sina Linux hårdvaruraid pga bitröta.

Här står mera om CERNs bitröta studie:
http://storagemojo.com/2007/09/19/cerns-data-corruption-resea...
http://sun.systemnews.com/articles/129/2/storage/20833

Citat:

Ursprungligen inskrivet av Weeblie
Var ligger då oftast problemet hos dem som har drabbats av det? Jo, på mjukvaran. ZFS's checksummor är främst tänkt att skydda mot firmware-buggar och det är just där ZFS har misslyckats här.

Jasså, det var intressant! Kan du ge länkar till detta påstående? Firmware buggar, säger du? Och på vilket sätt har ZFS misslyckats med dem? Kan du förklara?

Du skriver först:
"Att skylla på att ZFS bli "lurad" av VB är som att skylla på att bit-röta sker eftersom RAID-5 blir "lurad" av S.M.A.R.T."

Citat:

Ursprungligen inskrivet av Weeblie
Googles undersökning säger inte emot det jag har skrivit. S.M.A.R.T.'s ursprungliga huvudsyfta är att förutsäga när en disk håller på att dö, vilket den av erfarenhet och Googles undersökning visar sig vara långt ifrån idiotsäker (enbart runt hälften av fallen upptäcks i tid).

RAID-5 skyddar inte mot bitröta, vilket CERN undersökning visar. Och den som litar på SMART bör sluta göra det, eftersom SMART är skräp, vilket Googles undersökning visar.

Så jag ser inte den koppling du gör här.
ZFS blir lurad av VB. Detta menar du, är samma sak som att "RAID-5 blir lurad av SMART, och därför uppkommer bitröta"? Men RAID-5 skyddar inte mot bitröta, de har inget med varandra att göra. Så jag förstår inte din koppling. Det är som att säga "månen är gul, därför ska jag duscha" - de har inget med varandra att göra.

Citat:

Ursprungligen inskrivet av Weeblie
Men disken kan/ska också rapportera när en sektor läses in och triggar felkorrigeringskoden alternativt checksumman; d.v.s. kombinerat med RAID så ska man ha ett fullt tillräckligt skydd utan att behöva ta in ZFS.

Ja, om du tror att du får ett fullt tillräckligt skydd endast med RAID så får du tro det. CERNs stora undersökning säger annorlunda. Men fine, fortsätt du med RAID. Du behöver inte läsa CERNs undersökning.

Du behöver heller inte läsa på komplett.se, valfri disk:
http://www.komplett.se/k/ki.aspx?sku=575186&view=detailed#Pro...
"Oåterkalleligt fel - 1 per 10^15"
Dvs, det blir massor av fel hela tiden. Ett fel per 10^15 kan disken inte reparera. Dagens diskar är snabba, och med ett stort raid så har man snart läst 10^15 bits ganska snabbt. Och då har man ett fel.

Citat:

Ursprungligen inskrivet av Weeblie
Jag förstår inte ditt resonemang här.

Du skriver "Att skylla på att ZFS bli "lurad" av VB är som att skylla på att bit-röta sker eftersom RAID-5 blir "lurad" av S.M.A.R.T."

Men det stämmer inte, anser jag. RAID-5 skyddar inte mot bitröta, är inte designat för det vilket CERN visar. SMART skyddar inte heller mot bitröta, vilket CERN visar. Du säger nåt i stil med "jag åt omega-3 som är bra för hjärnan, men jag blev skjuten i huvudet och blev skadad, alltså är omega-3 skräp". Omega 3 skyddar inte mot skott i huvudet. Bitröta och RAID-5 och SMART har inget med varandra att göra. RAID-5 och SMART detekterar inte och kan inte korrigera bitröta.

Citat:

Ursprungligen inskrivet av Weeblie
När ZFS får problem så skyller man på billig hårdvara som inte följer standarder, trots allt prisande om att man inte behöver ta till dyra diskar och dyra disk-kontrollers när man använder sig av ZFS.

När "klassisk" RAID-5/6 får problem så skyller man på RAID-5/6 och inte diskarna som inte rapporterar de fel den kan göra.

Alltså, ZFS måste inte använda dyra diskar. Däremot är det bra om diskarna följer standarder och inte avviker från dem. Det kan orsaka problem om ZFS blir lurad av billig hårdvara. Om diskarna inte följer standarder, så kan ZFS inte göra något. Om disken säger att den gjort det ZFS sa åt den, men disken inte gjort det - då kan det bli problem.

Om du tror att RAID-5 inte heller lider av såna här problem med billig hårdvara, så får du tro det. Saken är den att ZFS är mycket känsligare än RAID-5 och därför detekterar och rapporterar många fler fel än RAID-5 gör. RAID-5 märker inte ens att det är problem, så du får mycket färre felmeddelanden med RAID-5. Färre felmeddelanden betyder inte att RAID-5 är säkrare. Istället skyller man felet t.ex. på Windows, när det kanske inte alls är Windows fel.

Citat:

Ursprungligen inskrivet av Weeblie
ps. Det är värt att notera här att när ZFS dör så har den en tendens att dö katastrofalt, troligen p.g.a. av komplexiteten på filsystemet. "Klassisk" RAID-5/6, även mjukvarubaserad sådan, kombinerat med ett enkelt filsystem som UFS verkar vara mer robust när olyckan väl är framme.

När du skriver data på ZFS, så ligger det gamla datat kvar. Det nya skrivs på ett nytt ställe på disken. Alla data ligger kvar. Det är inte som UFS och andra filsystem som skriver över allt gammalt.

Om du vet vad du gör, så kan du få tillbaka din ZFS raid igen. Det fanns inte verktyg tidigare för att få tillbaka en kraschad ZFS raid, men det finns det nu. Nyligen kom det.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Jag förstår inte hur du drog denna slutsats. Kan du förklara en gång till? Tankesprånget du gjorde, var lite för stort för mig.

Varje led i hårdvaran är skyddad av checksummor och felkorrigeringskoder.

För att citera CERN's dokument ( http://indico.cern.ch/getFile.py/access?contribId=3&sessionId... ):

1. The memory is capable of correcting single bit error.
2. The cache in the processor is ECC protected.
3. PCIe and SATA connections have CRC implemented.
4. The disk cache has ECC memory and the physical writing to disk has as well ECC as CRC in a complicated manner implemented to correct up to 32 byte errors (per 256 bytes) and detect any data corruption. The data is actually 5 times encoded before it reaches physically the disk.

Om alla firmwares fungerar som tänkt och även rapporterar korrigerade fel så att hårdvaran kan bytas ut (vilket inte all hårdvara gör; speciellt inte billigare sådan), ja då är chansen att något fel slinker igenom statistiskt sett obefintlig.

Citat:

Ursprungligen inskrivet av saddam
Du har inte läst CERNs undersökning som visade att de hade fel i sina filer, utan att disken, eller raidet eller någon annan hårdvara rapporterade att det var fel? CERN skrev ett förutbestämt bit mönster på Linux hårdvaruraid. Efter några veckor, så skannades alla filer igenom och CERN tittade på om någon fil avvek från det bestämda bitmönstret. CERN hittade 500 avvikelser på 100 hårdvaruraid, det var alltså fel, dvs bitröta.

Undersökningen nämner ingenting om vilken hårdvara som har använts. På grund av den mängd data som CERN behandlar så kan man inte göra antagandet att enbart sitter på ordentlig (enterprise) hårdvara. Felrapportering är något som oftast skiljer sig kraftigt mellan billigare och dyrare varianter.

Google är ett klassiskt exempel på ett företag som använder sig av kluster av billiga "slit-och-släng" datorer och fixar redundans i mjukvara istället.

En hårddisk som är korrekt byggd ska alltid kunna korrigera enkel bit-fel. Det finns inga enkel bit-fel som inte kan upptäckas av felkorrigeringen. Bit Error Rate ska enbart syfta på dem fel som slinker igenom felkorrigeringen. Det är därför som vi har ytterliggare ett lager ovanpå med en CRC checksumma. Så länge som disken raporterar att CRC checksumman inte stämde så kan ett ordentligt RAID-kortet korrigera felet.

Citat:

Ursprungligen inskrivet av saddam
Hårdvaran upptäckte inte dessa fel, och hur ska hårdvaran kunna korrigera dessa fel om den inte ens känner till felen? Men du menar att dessa fel "bör vara hårdvarumässigt en omöjlighet"? Det bör inte kunna inträffa, det räcker att skydda sig med hårdvaruraid, som CERN gjorde? CERN tycker uppenbarligen inte som du. CERN håller faktiskt på att implementera ZFS nu, på Solaris. CERN är inte nöjda med sina Linux hårdvaruraid pga bitröta.

Jasså, det var intressant! Kan du ge länkar till detta påstående? Firmware buggar, säger du? Och på vilket sätt har ZFS misslyckats med dem? Kan du förklara?

"64k regions of corrupted data, one up to 4 blocks (large correlation with the 3ware-WD disk drop-out problem) (80% of all errors)"
"After some long discussions with 3Ware and our hardware vendors this was identified as a problem in the WD disk firmware."

Hårdvaru-RAID har kända problem. De förlistar sig mycket på att firmwaren för diskarna är vettiga. Det finns fler än jag som anser att "ZFS's checksummor är främst tänkt att skydda mot firmware-buggar...". Se t.ex. http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data

För att sedan ta citaten i din post:

"It is quite simple -- ZFS sent the flush command and VirtualBox ignored it."
"consumer grade hardware is reporting to ZFS that writes have succeeded, when in fact they are still in the cache."

Är inte det ett klart exempel på där ZFS har "misslyckats" med sin uppgift? Undermålig firmware som inte talar sanningen har fått en ZFS pool at falla?

Citat:

Ursprungligen inskrivet av saddam
Du skriver först:
"Att skylla på att ZFS bli "lurad" av VB är som att skylla på att bit-röta sker eftersom RAID-5 blir "lurad" av S.M.A.R.T."

RAID-5 skyddar inte mot bitröta, vilket CERN undersökning visar.

Hårdvaru-RAID är baserat på att diskarna själva rapporterar felen. Icke-korrigerbar bit-röta som rapporteras till kontrollern kan korrigeras.

Hela kedjan skyddas mot bit-flipar som sker på grund av kosmisk strålning, disk-krascher och dylikt. Hårdvaru-RAID har huvudsakligen som enda svaghet att "tillverkningsrelaterade" fel inte upptäcks. D.v.s. hårdvaru eller mjukvaru/firmware-problem som redan fanns där vid leverans.

Kikar du på CERNs studie så ser du att dubbel-bit fel upptäcktes i minnet. De ska statisktiskt sett aldrig ske, men nu när de ändå gör det så skulle de också göra ens vacrka ZFS pool korrupt.

Ta bort de fel som uppstod av WD's trasiga firmware och man är nere på att ZFS som bäst förbättrar med en storleksordning. RAID 6 som skrubbas och man verkar vara nere på samma nivåer som RAID-Z (dock så fixas de fixbara problemen "online" med RAID-Z medan "offline" med RAID-6).

Citat:

Ursprungligen inskrivet av saddam
Och den som litar på SMART bör sluta göra det, eftersom SMART är skräp, vilket Googles undersökning visar.

Suck. Har du ens läst Googles undersökning?

Googles undersökning är om "katastrofala" disk-förluster och har inget med mjuka bit-flippar att göra. Deras slutsats antyder inte ens om att man ska ignonera S.M.A.R.T. utan förespråkar bara att man samtidigt också ska använda sig av andra modeller för att förutspå dessa problem med individuella diskar.

Citat:

Ursprungligen inskrivet av saddam
Så jag ser inte den koppling du gör här.
ZFS blir lurad av VB. Detta menar du, är samma sak som att "RAID-5 blir lurad av SMART, och därför uppkommer bitröta"? Men RAID-5 skyddar inte mot bitröta, de har inget med varandra att göra. Så jag förstår inte din koppling. Det är som att säga "månen är gul, därför ska jag duscha" - de har inget med varandra att göra.

- Hårddiskar använder sig oftast av CRC-checksummor utöver felkorrigeringskoderna.
- Ordentliga RAID-kontrollers som får reda på att CRC-checksumman inte matchar kan använda de andra diskarna för att reparera felet.
- RAID-5 kan därmed, precis som RAID-Z, korrigera bit-röta som flippas på en enskild hårddisk.

Citat:

Ursprungligen inskrivet av saddam
Ja, om du tror att du får ett fullt tillräckligt skydd endast med RAID så får du tro det. CERNs stora undersökning säger annorlunda. Men fine, fortsätt du med RAID. Du behöver inte läsa CERNs undersökning.

Jag har läst CERNs undersökning från sida till sida men känner också till stora serverparker som tuffar på alldeles utmärkt med "klassiska" RAID-lösningar.

Citat:

Ursprungligen inskrivet av saddam
Du behöver heller inte läsa på komplett.se, valfri disk:
http://www.komplett.se/k/ki.aspx?sku=575186&view=detailed#Pro...
"Oåterkalleligt fel - 1 per 10^15"
Dvs, det blir massor av fel hela tiden. Ett fel per 10^15 kan disken inte reparera. Dagens diskar är snabba, och med ett stort raid så har man snart läst 10^15 bits ganska snabbt. Och då har man ett fel.

"Oåterkalleligt fel" != "Odetekterbart fel"

Citat:

Ursprungligen inskrivet av saddam
Du skriver "Att skylla på att ZFS bli "lurad" av VB är som att skylla på att bit-röta sker eftersom RAID-5 blir "lurad" av S.M.A.R.T."

Men det stämmer inte, anser jag. RAID-5 skyddar inte mot bitröta, är inte designat för det vilket CERN visar. SMART skyddar inte heller mot bitröta, vilket CERN visar. Du säger nåt i stil med "jag åt omega-3 som är bra för hjärnan, men jag blev skjuten i huvudet och blev skadad, alltså är omega-3 skräp". Omega 3 skyddar inte mot skott i huvudet. Bitröta och RAID-5 och SMART har inget med varandra att göra. RAID-5 och SMART detekterar inte och kan inte korrigera bitröta.

Se tidigare svar.

Citat:

Ursprungligen inskrivet av saddam
Alltså, ZFS måste inte använda dyra diskar. Däremot är det bra om diskarna följer standarder och inte avviker från dem. Det kan orsaka problem om ZFS blir lurad av billig hårdvara. Om diskarna inte följer standarder, så kan ZFS inte göra något. Om disken säger att den gjort det ZFS sa åt den, men disken inte gjort det - då kan det bli problem.

Om du tror att RAID-5 inte heller lider av såna här problem med billig hårdvara, så får du tro det. Saken är den att ZFS är mycket känsligare än RAID-5 och därför detekterar och rapporterar många fler fel än RAID-5 gör. RAID-5 märker inte ens att det är problem, så du får mycket färre felmeddelanden med RAID-5. Färre felmeddelanden betyder inte att RAID-5 är säkrare. Istället skyller man felet t.ex. på Windows, när det kanske inte alls är Windows fel.

Budget RAID-lösningar är verkligen en dödssynd.

Citat:

Ursprungligen inskrivet av saddam
När du skriver data på ZFS, så ligger det gamla datat kvar. Det nya skrivs på ett nytt ställe på disken. Alla data ligger kvar. Det är inte som UFS och andra filsystem som skriver över allt gammalt.

Om du vet vad du gör, så kan du få tillbaka din ZFS raid igen. Det fanns inte verktyg tidigare för att få tillbaka en kraschad ZFS raid, men det finns det nu. Nyligen kom det.

Med allt detta sagt så gillar jag egentligen ZFS. Det är nytt och fräscht och har många finesser som verkligen är en administratörs dröm.

ZFS är däremot inte en "silver bullet" när det kommer till dataintegritet, vilket många försöker få det att låsa som.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
ZFS är däremot inte en "silver bullet" när det kommer till dataintegritet, vilket många försöker få det att låsa som.

Jag tror ingen menar att ZFS är botemedlet mot alla lagringsproblem, jag har själv skrivit om flera problem med ZFS här. Däremot är det många som menar att ZFS är det bästa realistiska lösningen som vi kan använda idag.

Angående dina påståenden om ZFS så är många av dem helt felaktiga. Men jag orkar inte tjafsa om detta med dig. Du har ju bevisligen haft många fel tidigare. Det tar sån tid att slå hål på din FUD och vanföreställningar. Vi har haft diskussion om ZFS tidigare, du och jag. Jag har förklarat flera ggr och givit flera länkar tidigare att RAID inte skyddar mot bitröta, till ingen nytta. Jag har visat en drös med länkar att RAID har andra problem. Du fortsätter påstå tvärtom. Fine.

CERN samlar data från maskiner som kostar många miljarder kr, som planerats och byggts i tiotals år. Datat kostar bokstavligen miljarder kr att få fram. Om du verkligen tror CERN kör billiga RAID lagringslösningar så får du tro det. Tror du CERN inte bryr sig om de får bitflip så får du tro det. CERN gjorde studie som visade att hårdvaruraid inte är att lita på. Om du tror tvärtom mot vad CERNs studie visar, så får du tro det. CERN har nu börjat köpa in ZFS baserade SUN lagringsservrar, och SUN maskiner är inte billiga. Du får fortsätta tro att CERN kör billiga lagringslösningar och skiter i säkerheten av sina data som kostar miljarder att få fram. Fine. (Man kan bli trött för mindre).

Jag säger istället så här. Du får fortsätta tro att RAID-5 skyddar mot bitröta och att ZFS endast skyddar mot firmware errors. Ni andra kan läsa dessa akademiska studier av dataforskare istället.

En forskare undersöker NTFS, ext3, ReiserFS, JFS och XFS med avseende på datasäkerhet. Det finns länk till själva avhandlingen här. Slutsatsen är att alla de filsystemen suger. Och:
"And you enterprise data center folks, smirking over the junk consumers get, don’t be too smug. Some of your costly high-end storage servers have NTFS or Linux FS’s under the hood as well. And no, RAID doesn’t fix these problems."
http://blogs.zdnet.com/storage/?p=169
Det finns många fler rapporter om folk fått fel med hårdvaruraid, men de rapporterna uppmärksammas inte. Så när du läser att folk får fel med ZFS, så är det egentligen ovanligare.

Här har vi några dataforskare som analyserar ZFS. Genomskumning av artikeln visar att forskarna kommer fram till att ZFS behöver ECC minne för att funka som tänkt. Annars är inte ZFS jättesäkert. Men ZFS lyckades detektera alla diskfel och skulle kunnat korrigera alla felen, om forskarna använt ZFS raid. Men forskarna körde bara single disk, så ZFS kunde inte reparera precis alla felen, bara en del av dem.
http://www.cs.wisc.edu/wind/Publications/zfs-corruption-fast1...
Sen ställer forskarna till det i RAM och visar att då får ZFS problem. Det kanske inte är så konstigt. ZFS skriver ned det som är i RAM. Om nån ställer till det som är i RAM, ja, datat blir nedkopierat på disk. Om datat är fel i RAM, då kan inte ZFS veta om datat är fel eller rätt. ZFS bara garanterar att allt skrivs ned på disk korrekt. Förutsatt att disken funkar som det är tänkt, dvs inte lurar ZFS.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Angående dina påståenden om ZFS så är många av dem helt felaktiga. Men jag orkar inte tjafsa om detta med dig. Du har ju bevisligen haft många fel tidigare. Det tar sån tid att slå hål på din FUD och vanföreställningar. Vi har haft diskussion om ZFS tidigare, du och jag. Jag har förklarat flera ggr och givit flera länkar tidigare att RAID inte skyddar mot bitröta, till ingen nytta. Jag har visat en drös med länkar att RAID har andra problem. Du fortsätter påstå tvärtom. Fine.

Jag säger istället så här. Du får fortsätta tro att RAID-5 skyddar mot bitröta och att ZFS endast skyddar mot firmware errors. Ni andra kan läsa dessa akademiska studier av dataforskare istället.

Jag har skrivit om och om igen att odetekterbara bit-flippar inte kan ske på moderna hårddiskar, så länge som det inte finns någon form av tillverkningsfel (t.ex. firmware buggar).

Du har inte pekat på en enda källa som pekar på motsatsen. Orsaken är enkel: det är en matematisk omöjlighet att ha ett bit-mönster med en flippad bit och som inte kan detekteras av varken felkorrigeringskoderna och checksummorna.

Jag vet inte om det är brist på kunskaper eller liknande som gör att du inte kan inse att klassisk RAID skyddar mot bit-röta. Det enda som krävs är att hårddiskarna checksummar varje sektor och rapporterar felen, vilket en ordentlig disk ska/kan göra. Precis som att det enda som krävs för att ZFS-problemet du beskrev tidigare inte ska dyka upp är att hårddiskarna implementerar skrivcachen korrekt. Sker detta alltid? Nej

[Man opererar också under antagandet att RAID-firmwaren inte har buggar i sig, vilket inte alltid är sant, speciellt för budget varianter.]

Jag har tekniskt beskrivit varför en vanlig RAID-5/6 lösning fortfarande fungerar finfint och att de flesta problem som uppstår beror på otestad hårdvara alternativt hårdvara med kända problem. Om en viss serverkonfiguration har sålts i hundratusentals och snurrar dagligen på finfint i serverparker runt om i världen så betraktar jag lösningen som OK.

Vem är det dessutom som sprider Fear-Uncertainty-Doubt? Jag försvarar RAID-5/6. Du är på offensiven. Jag vet inte om du jobbar på SUN eller hos en av deras återförsäljare eller ej, men att upprepa "bit-röta", "bit-röta" och sedan länka till samma CERN-studie (som dessutom pekar ut firmwares som det största problemet) och klanka ner på alla klassiska filsystem; om det inte är FUD så vet jag inte vad FUD är.

Du verkar dessutom aktivt ignonera att CERNs rapport även visar på okorrigerbara dubbel-bitflippar i minnet. Lägg på faktumet (som vi ser från dem andra forumtrådarna du länkade till tidigare) att ZFS verkar vara mycket sårbart vid metadatakorruption och det hela blir beskymmersamt.

Citat:

Ursprungligen inskrivet av saddam
Slutsatsen är att alla de filsystemen suger.

Till skillnad från dig så har jag aldrig någonsin (åtminstonde avsiktligt) antytt om att ZFS skulle suga. Det är ett fanboy-beteende och hör inte hemma vid en objektiv diskussion.

Citat:

Ursprungligen inskrivet av saddam
Här har vi några dataforskare som analyserar ZFS. Genomskumning av artikeln visar att forskarna kommer fram till att ZFS behöver ECC minne för att funka som tänkt. Annars är inte ZFS jättesäkert. Men ZFS lyckades detektera alla diskfel och skulle kunnat korrigera alla felen, om forskarna använt ZFS raid. Men forskarna körde bara single disk, så ZFS kunde inte reparera precis alla felen, bara en del av dem.
http://www.cs.wisc.edu/wind/Publications/zfs-corruption-fast1...
Sen ställer forskarna till det i RAM och visar att då får ZFS problem. Det kanske inte är så konstigt. ZFS skriver ned det som är i RAM. Om nån ställer till det som är i RAM, ja, datat blir nedkopierat på disk. Om datat är fel i RAM, då kan inte ZFS veta om datat är fel eller rätt. ZFS bara garanterar att allt skrivs ned på disk korrekt. Förutsatt att disken funkar som det är tänkt, dvs inte lurar ZFS.

Jag uppskattar att ZFS har mjukvarubaserade checksummor på blocken eftersom "kedjan" av kontrollers är lång och varje steg är idag väldigt komplex. Det hela blir ett extra skydd ovanpå de lager man redan har. Med introduktionen av CRC32C-instruktionen hos SSE4.2 (och om ZFS-implementionerna hos x86 adopterar dem) så kan man dessutom få denna utökade säkerhet i utbyte mot i princip noll extra CPU-kraft.

Men som sagt, det jag finner beskymmersamt (obs! inte "ZFS suger") är komplexiteten hos filsystemet. Att något så enkelt som att skrivcachen "luras" kan leda till en härdsmälta hos ZFS + RAID-Z är mindre bra.

Kommer jag att byta från ZFS + RAID-Z till UFS + RAID-6 på min filserver efter att ha hört detta? Nej.
Tycker jag att SUN borde kika lite extra på detta? Ja.

Deal-breakern för mitt fall är ZFS snapshots (eller snarare att UFS "snapshots"/dump är mycket mindre bekväma).

Jag är å andra sidan inte så exatisk över RAID-Z att jag vägrar köra ZFS med klassisk hårdvaru RAID-6 om det finns skäl för det (t.ex. att man placerar VMware ESXi mellan).

Permalänk
Avstängd

Weeblie
Det jag vänder mig emot är att det verkar som att du anser ZFS har stora brister, men du nämner inte ett ord om RAIDs mycket större brister. Som jag visat tidigare så är somliga av dina påstådda ZFS brister bara ren missuppfattning från din sida, t.ex. när du påstår att det inte går att få ut hög IOPS från ZFS. Du hackar ned på ZFS och får det att låta som att hårdvaru RAID är minst lika säkert - vilket inte är sant. FUD eller missuppfattning? Missuppfattning föreligger när du efter att läst länkar som visar att du har fel så du slutar påstå felaktiga saker, du inser att du haft fel. FUD föreligger när man visar dig massor av länkar som visar att du har fel, och trots det, så fortsätter du påstå de felaktiga sakerna. (Apropås att du påstår att jag FUDar, var det inte du som var ganska snabb på att anklaga andra för FUD? Jag är inte snabb med anklaga andra för FUD, däremot.)

Jag har upprepade ggr förklarat att vanlig hårdvaruraid RAID inte skyddar dina data, det har jag pratat mycket om, och givit många länkar som visar det. Du har sett de länkarna, och trots det så påstår du motsatsen.

Bl.a. har jag visat CERN studien som visar att datat som kördes på h/w raid blev korrupt. Och du verkar mena att nej, datat var inte alls korrupt? Men datat var ju korrupt trots h/w raid - som är lika säkert som ZFS, enligt dig. Hur kan datat bli korrupt om h/w raid är säkert? Eller så menar du att CERNs korrupta data berodde endast på fel på diskarnas firmware, men att även ZFS skulle haft samma problem i samma situation? Men samtidigt så skriver du att ZFS endast är till för att skydda mot firmware problem - så ZFS hade inte alltså inte haft firmware problemen. I vilket fall som helst, h/w raid som är så säkert enligt dig, fick massa silent corruption enligt CERNs undersökning. Så du kanske kan låta bli att påstå att h/w raid är lika säkert som ZFS? Jag påstår att ZFS skyddar dina data mycket bättre än h/w raid - mot detta har du invändningar. Kan du sluta invända? Eller känner du till att ZFS är säkrare än h/w raid, men ljuger medvetet, dvs FUDar? Missuppfattning eller FUD? Man kan bli trött för mindre.

Citat:

Ursprungligen inskrivet av Weeblie
Jag vet inte om det är brist på kunskaper eller liknande som gör att du inte kan inse att klassisk RAID skyddar mot bit-röta. Det enda som krävs är att hårddiskarna checksummar varje sektor och rapporterar felen, vilket en ordentlig disk ska/kan göra.

Enligt disktillverkare så får en disk ett oåterkallerligt fel, 1 bit per 10^15 bitar. Såna fel går alltså inte att reparera. Hur går detta ihop, om det funkar som du säger? Missuppfattning återigen? De flesta felen kan man upptäcka och korrigera, men det finns sällsynta fel som inte ens kan upptäckas. De felen är ännu värre. Hur kan man korrigera nåt man inte ens kan detektera?

En modern disk har minst 20% av ytan dedikerad till felkorrigeringar, det blir massor av fel vid varje läsning som korrigeras on-the-fly, men alla felen kan inte korrigeras, pga olika faktorer. Kan du tänka dig ett scenario där disken skriver ned en 1:a korrekt men efteråt så råkas biten flippas pga något skäl, kanske strömspik, kosmisk strålning, whatever? Då hjälper bara ZFS "scrub". En del sällsynta fel kan inte ens detekteras.

Det är alltså inte så enkelt som du tror att skydda sina data mot silent corruption. Data ska kopieras i en lång kedja ned till disken. Det kan finnas brister i vilken länk som helst.

Här nedan ser vi att en felaktig switch corruptade datat, och ingen märkte det. All hårdvara, dvs varje mellansteg (inkl diskar) rapporterade att allt var bra i varje steg. Det var endast ZFS som kunde detektera att det som fanns i RAM inte var samma som skrevs på disk. Detta kan inte h/w raid kontrollera. ZFS är säkrare än h/w raid. Kan du sluta invända? Eller FUDar du?
http://jforonda.blogspot.com/2007/01/faulty-fc-port-meets-zfs...

Till TS. Gör som du vill, men jag själv skulle aldrig köra en filserver virtuellt. Som jag visat så kan det bli problem, även med ZFS. ZFS är mycket känsligare än andra filsystem så det detekterar massor med problem som ingen annan upptäcker. T.ex. NTFS skulle glatt rapportera att du inte har några fel alls, men ZFS upptäcker det direkt. Företag håller tyst om Silent Corruption, påstår en snubbe:
http://www.enterprisestorageforum.com/sans/features/article.p...

Angående CERNs h/w raid studie:
"Panzer-Steindel writes that the fact that the disk probe regularly reports corruption errors shows clearly that the different protection mechanisms don’t work 100%"
Mao, h/w raid är inte säkert. Kan du sluta invända eller FUDar du?

http://hpc-events.com/sun-dresden07/CERN_Gasthuber.pdf
CERN skriver på sidan 16 att endast "ZFS solves critical data integrity cases" och att såna lagringsfel är "seen on all types of HW" - oavsett pris, dvs även mycket dyra Enterprise lagringslösningar har problem. Mao, h/w raid är inte säkert. CERN har börjat köpa in ZFS maskiner. Kan du sluta invända, eller FUDar du?

Kan du sluta skriva saker som

Citat:

Ursprungligen inskrivet av Weeblie
fel som inte bara är okorrigerbara men också odetekterbara, bör därför hårdvarumässigt vara en (i princip) omöjlighet.

Man kan bli trött för mindre. Såna fel inträffar i massor, jag har igen visat länkar som visar att du har fel. Flera av de länkarna är visade här tidigare i samband med ZFS diskussioner, du har sett dem tidigare men ändå påstår du märkliga saker. FUDar du eller läser du inte mina länkar?

Eller har jag bara missförstått dig?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Jag har upprepade ggr förklarat att vanlig hårdvaruraid RAID inte skyddar dina data, det har jag pratat mycket om, och givit många länkar som visar det. Du har sett de länkarna, och trots det så påstår du motsatsen.

Du har upprepande gånger postat samma länkar (eller snarare "länken") som visar när hårdvaru-RAID har misslyckats. Du har också postat länkar som visar när ZFS har misslyckats katastrofalt.

Jag förstår inte hur någon kan så fullständigt sopa det ena under mattan och så hårt klanka ner på det andra.

Citat:

Ursprungligen inskrivet av saddam
Bl.a. har jag visat CERN studien som visar att datat som kördes på h/w raid blev korrupt. Och du verkar mena att nej, datat var inte alls korrupt?

Försök inte att lägga ord i munnen på andra. Läste du vad som faktiskt står i rapportern? D.v.s. inte bara stirrade dig blint på "500 fel"?

För att vara riktigt observant så står det inte i rapportern att alla systemen ens använde sig av RAID-5. Om du kikar under rubriken "RAID 5 verification" så ser du att det står "492 systems"; varför körde de inte testet på alla deras 3000 noder?

Jag kan enbart se två möjligheter här:

1. De körde inte RAID-5 på alla deras servrar. Det är oftast inte nödvändigt att göra det på CPU-servrar.
2. De körde enbart VERIFY på 492 system och inte på resten.

Låt oss anta att alternativ 2 var det som skedde här. Att "scrubba" RAID-5 fixar då enligt CERN ungefär 300 / (492 * 4) = 0,152439 block-fel per nod och vecka. Extrapolera det över resten av (3000 - 492) = 2508 maskinerna och 5 veckor och du får att runt 1900 block-fel borde ha fixats. Detta är många fler än dem 500 fel som upptäcktes!

Du kan själv dra vilka slutsatser du vill från detta, men personligen finner jag att alternativ 1 är mer troligt.

Citat:

Ursprungligen inskrivet av saddam
Men datat var ju korrupt trots h/w raid - som är lika säkert som ZFS, enligt dig. Hur kan datat bli korrupt om h/w raid är säkert?

Jag har aldrig påstått att hårdvaru-RAID är felfritt.

Men vad du därmed försöker ge sken av är att ZFS är idiotsäkert, speciellt om ZFS får köra på "ordentlig hårdvara som implementerar skriv-cachen korrekt". Det är fel.

Låt oss återigen gå tillbaka til CERN's rapport.

De skriver att "We have 44 reported memory errors (41 ECC and 3 double bit) on ~1300 nodes during a period of about 3 month.". ~1300 noder och 3 månader är mer eller mindre ekvivalent med 3000 noder och 5 veckor.

Som du själv har sagt så kan varken ZFS (eller något annat filsystem för den delen) eller hårdvaru-RAID skydda mot dessa fel.

Vi har då som bäst att ZFS får 3 fel vs 500 (antagandet att de flesta okorrigerbara bit-felen här faktiskt leder till datakorruption/dataförlust är inte så långsökt med tanke på att work-loaden gör att minnesoperationerna domineras av inläsning/skrivningar till buffertar).

Exkluderar du firmware-problemet med WD-diskarna (80%) så är man nere på 3 vs 100 som bäst. Se nedan för förklaring på hur man stänger gapet med enterprise-hårdvara.

Citat:

Ursprungligen inskrivet av saddam
Eller så menar du att CERNs korrupta data berodde endast på fel på diskarnas firmware, men att även ZFS skulle haft samma problem i samma situation? Men samtidigt så skriver du att ZFS endast är till för att skydda mot firmware problem - så ZFS hade inte alltså inte haft firmware problemen.

"endast på fel på diskarnas firmware" - Var har jag skrivit det? CERNs rapport skriver dock klart och tydligt att majoriteten av problemen härstämmade från ett firmware-problem med WD-diskarna.

"ZFS skulle haft samma problem i samma situation" - Beroende på hur diskarna föll ur så skulle ZFS kanske inte ha ökat upptiden. Men från en dataintegritetssynvinkel så har ZFS end-to-end skydd och det kan man inte komma ifrån. Precis som jag skrev tidigare så skulle ZFS däremot också ha drabbats av bit-flipparna i minnet. Det skulle bara kunna ha fixats om man hade stegat upp till ännu bättre hårdvara (se senare).

"ZFS endast är till för att skydda mot firmware problem" - Skilj på "endast" och "främst". Läs denna länk igen: http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data

Citat:

Ursprungligen inskrivet av saddam
I vilket fall som helst, h/w raid som är så säkert enligt dig, fick massa silent corruption enligt CERNs undersökning. Så du kanske kan låta bli att påstå att h/w raid är lika säkert som ZFS? Jag påstår att ZFS skyddar dina data mycket bättre än h/w raid - mot detta har du invändningar. Kan du sluta invända? Eller känner du till att ZFS är säkrare än h/w raid, men ljuger medvetet, dvs FUDar? Missuppfattning eller FUD? Man kan bli trött för mindre.

Ja, man blir trött för mindre eftersom du envisas med att höja ZFS upp till skyarna.

Citat:

Ursprungligen inskrivet av saddam
Enligt disktillverkare så får en disk ett oåterkallerligt fel, 1 bit per 10^15 bitar.

Korrekt.

Citat:

Ursprungligen inskrivet av saddam
Såna fel går alltså inte att reparera.

Korrekt.

Citat:

Ursprungligen inskrivet av saddam
Hur går detta ihop, om det funkar som du säger? Missuppfattning återigen? De flesta felen kan man upptäcka och korrigera, men det finns sällsynta fel som inte ens kan upptäckas. De felen är ännu värre. Hur kan man korrigera nåt man inte ens kan detektera?

Vet du vad skillnaden mellan en felkorrigeringskod och en checksumma är?

Fel som inte kan korrigeras (BER - mer om det senare) är inte ekvivalenta med fel som inte kan detekteras. Diskar med bägge felkorrigeringskoder och checksummor kan upptäcka fel långt över sin korrigerbara gräns.

Citat:

Ursprungligen inskrivet av saddam
En modern disk har minst 20% av ytan dedikerad till felkorrigeringar, det blir massor av fel vid varje läsning som korrigeras on-the-fly, men alla felen kan inte korrigeras, pga olika faktorer. Kan du tänka dig ett scenario där disken skriver ned en 1:a korrekt men efteråt så råkas biten flippas pga något skäl, kanske strömspik, kosmisk strålning, whatever? Då hjälper bara ZFS "scrub". En del sällsynta fel kan inte ens detekteras.

Jag tycker att du har allvarliga brister på teori-fronten här. Det är en matematisk omöjlighet att en enda flippad bit skapar ett sådant bit-mönster att det t.ex. slinker igenom Reed-Solomon koder (som typiskt används i hårddiskar). Det är också en matematisk omöjlighet att bit-flippar paserar en 32/64-bitars CRC kontroll om antalet bitar som flippas är färre än 32/64.

Det är vidare matematiskt sett oerhört osannolikt att CRC-testet passeras även om fler bitar flippas. Man kan dock argumentera sig blå om de relativa styrkorna mellan ZFS's 256-bitars fletcher2/4 implementation och CRC-32/64. Det senare är egentligen mer lämpat för sådana fel som brukar uppkomma på lagringsmedier men 256 bitar vs 32/64 bitar är trots allt 256 vs 32/64.

Vad betyder detta för oss konsumenter? Jo, att bit-flippar "aldrig" ska ske odetekterade på diskar med både felkorrigeringskoder och checksummor. Hur hårddisken eller RAID-kontrollern hanterar ett sådant fall är en annan femma.

Citat:

Ursprungligen inskrivet av saddam
Angående CERNs h/w raid studie:
"Panzer-Steindel writes that the fact that the disk probe regularly reports corruption errors shows clearly that the different protection mechanisms don’t work 100%"
Mao, h/w raid är inte säkert. Kan du sluta invända eller FUDar du?

http://hpc-events.com/sun-dresden07/CERN_Gasthuber.pdf
CERN skriver på sidan 16 att endast "ZFS solves critical data integrity cases" och att såna lagringsfel är "seen on all types of HW" - oavsett pris, dvs även mycket dyra Enterprise lagringslösningar har problem. Mao, h/w raid är inte säkert. CERN har börjat köpa in ZFS maskiner. Kan du sluta invända, eller FUDar du?

Kan du sluta skriva saker som

Man kan bli trött för mindre. Såna fel inträffar i massor, jag har igen visat länkar som visar att du har fel. Flera av de länkarna är visade här tidigare i samband med ZFS diskussioner, du har sett dem tidigare men ändå påstår du märkliga saker. FUDar du eller läser du inte mina länkar?

Eller har jag bara missförstått dig?

Jag vill att du öppnar CERN's dokument igen: http://indico.cern.ch/getFile.py/access?contribId=3&sessionId...

Titta sedan på sida 4.

Vad visas där? Jo; CERN använder sig av SATA diskar (högst troligen för att bespara pengar med tanke på hur mycket diskutrymme de behöver). Låter det som en ordentlig server-lösning?

Jag erkänner att jag verkar ha överskattat SATA diskarnas förmåga att detektera fel genom att ta funktionalitet som jag vet existerar på SAS-diskar och sedan blandat ihop dem med de som finns på SATA-diskar. Men det gör CERNs konfiguration ännu mindre representativ för vad man kan få med hårdvaru-RAID på enterprise-nivå.

Klassiska RAID-problem sker inte som du säger från att bitar flippas av kosmisk strålning eller dylikt utan av mer "oanad" typ som t.ex. att hårddiskarna skriver fel sektor på fel plats. Dessa fel detekteras vanligen inte av hårddiskarna och leder därmed till tyst datakorruption. Firmware-buggar nämns ofta eftersom även de leder till tyst datakorruption. Alternativt så kan bit-flippar ske när data befinner sig i ett oskyddat tillstånd i t.ex. en mikrokontroller.

Enterprise SAS-diskar använder sig därför oftast av 520 byte sektorer istället för 512. Det tillåter enterprise RAID-lösningar att skriva dit extra checksummor och taggar för att se till att det verkligen är rätt sektor som läses in. Datatrafiken till och från RAID-kortet räknas som mycket säker (om du inte kan lita på sydbryggan så kan du nog inte heller lita på nordbryggan; och då är det irrelevant om du kör med ECC-minnen eller ej).

En typisk fel-kurva är "\___/"-formad. Även ordentliga RAID-lösningar kan ha sina problem. Men majoriteten av de fallen sker när lösningen är obeprövad (ny hårdvara?) eller när lösningen börjar närma sig end-of-life. När systemet väl ha testkörts i någon månad utan problem så är en hårdvaru-RAID lösning av enterprise nivå inte avsevärt sämre än det man får med ZFS; d.v.s. ingen av lösningarna förväntas ge korrupt data.

ZFS är bättre än hårdvaru-RAID från en dataintegritetssynvinkel eftersom ZFS ger ett mer komplett end-to-end skydd, precis som att applikations-specifika checksummor är ännu ett snäpp vassare (i princip för att se till att "ZFS firmwaren" i sig inte är korrupt).

Egentligen ville jag inte än en gång slöa tid på en "hårdvaru-RAID vs ZFS"-diskussion utan enbart höja en liten varningsflagga för den nuvarande ZFS implementationen.

SUN har länge förespråkat att man ska/kan använda sig av billiga hårdvaru-lösningar med en ordentlig mjukvaru-lösning istället för vice versa. Det blir då beskymmersamt att folk får dataförluster efter att ha följt detta "tips".

Betyder det att ZFS inte längre duger till budget-medvetet folk? Nej; det finns fortfarande inget alternativ som är bättre. Men vad man måste göra här är att kanske överväga att inaktivera skriv-cachen eller acceptera den lilla risken medan man väntar på att SUN gör ZFS ännu mer robust.

För enterprise-lagring så är diskussionen egentligen irrelevant. Man vet då antaligen vilka behov man har och kan själv överväga sina alternativ.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Du har upprepande gånger postat samma länkar (eller snarare "länken") som visar när hårdvaru-RAID har misslyckats. Du har också postat länkar som visar när ZFS har misslyckats katastrofalt.

Jag har visat många länkar som visar att hårdvaruraid inte är vidare säkert. Jag har postat många flera länkar i diskussioner om ZFS här. T.ex denna om RAID-5:
http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
"When a drive returns garbage, since RAID5 does not EVER check parity on read (RAID3 & RAID4 do BTW and both perform better for databases than RAID5 to boot) if you write a garbage sector back garbage parity will be calculated and your RAID5 integrity is lost! Similarly if a drive fails and one of the remaining drives is flaky the replacement will be rebuilt with garbage also propagating the problem to two blocks instead of just one."

Den här sajten är full av tekniska artiklar utav sysadmins som handlar om varför RAID-5 suger. Vad du än gör, använd inte RAID-5 menar de.
http://www.baarf.com/

Här har vi en artikel om matematiken bakom RAID-6:
http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
Marc skriver om den artikeln:
"The paper explains that the best RAID-6 can do is use probabilistic methods to distinguish between single and dual-disk corruption, eg. "there are 95% chances it is single-disk corruption so I am going to
fix it assuming that, but there are 5% chances I am going to actually corrupt more data, I just can't tell". I wouldn't want to rely on a RAID controller that takes gambles :-)"

HW RAID-6 kan inte få reda på vad det är för typ av fel, och RAID-6 gissar därför. Med risk att den korruptar än mer data. Grymt sa grisen.

Visst har ZFS misslyckats, det sticker jag inte under stol med. Jag försöker inte lura på folk att ZFS är 100% säkert och felfritt. Tvärtom vill jag tala om även dåliga saker med ZFS, försöka ge en hyfsat objektiv bild.

Citat:

Ursprungligen inskrivet av Weeblie
Jag förstår inte hur någon kan så fullständigt sopa det ena under mattan och så hårt klanka ner på det andra.

När folk påstår felaktiga saker så måste jag rätta dem. T.ex har ZFS överlägsen felkorrigering jfrt med h/w raid (som t.ex inte skyddar mot silent corruption och lider av write hole error) - inte är de likvärdiga. Jag har inget emot om du postar kritiska länkar och kritiserar ZFS, men då bör det finnas sanning i det. Påstår du felaktiga saker så invänder jag. Påstår du negativa, men sanna saker om ZFS så bryr jag mig inte. Det är bara bra om sanningen kommer fram. Negativ som positiv. Jag vill ju själv också veta, eftersom jag själv kör ZFS. Man kan ju inte bara läsa de positiva sakerna. Varför tror du jag själv postar negativa kritiska saker om ZFS? För att jag är en rabiat ZFS fanboy som försöker ge sken av att ZFS är 200% säkert?

Citat:

Ursprungligen inskrivet av Weeblie
Försök inte att lägga ord i munnen på andra. Läste du vad som faktiskt står i rapportern? D.v.s. inte bara stirrade dig blint på "500 fel"?

För att vara riktigt observant så står det inte i rapportern att alla systemen ens använde sig av RAID-5. Om du kikar under rubriken "RAID 5 verification" så ser du att det står "492 systems"; varför körde de inte testet på alla deras 3000 noder?

Jag kan enbart se två möjligheter här:

1. De körde inte RAID-5 på alla deras servrar. Det är oftast inte nödvändigt att göra det på CPU-servrar.
2. De körde enbart VERIFY på 492 system och inte på resten.

Låt oss anta att alternativ 2 var det som skedde här. Att "scrubba" RAID-5 fixar då enligt CERN ungefär 300 / (492 * 4) = 0,152439 block-fel per nod och vecka. Extrapolera det över resten av (3000 - 492) = 2508 maskinerna och 5 veckor och du får att runt 1900 block-fel borde ha fixats. Detta är många fler än dem 500 fel som upptäcktes!

Du kan själv dra vilka slutsatser du vill från detta, men personligen finner jag att alternativ 1 är mer troligt.

Jag drar FORTFARANDE slutsatsen att CERN kör hellre ZFS eftersom CERN fick datakorruption på h/w raid och CERN ser grava brister i h/w raid som gör det odugligt för deras behov. Vad drar du själv för slutsats? Att deras h/w raid är säkert och att CERN är nöjda? Jag fattar inte. CERN har BEVISLIGEN fel på sina h/w raid. Och ändå försvarar du h/w raid som en säker lösning?

Citat:

Ursprungligen inskrivet av Weeblie
Jag har aldrig påstått att hårdvaru-RAID är felfritt.

Men vad du därmed försöker ge sken av är att ZFS är idiotsäkert, speciellt om ZFS får köra på "ordentlig hårdvara som implementerar skriv-cachen korrekt". Det är fel.

Nej, jag försöker inte ge sken av att ZFS är idiotsäkert. Varför skulle jag posta länkar som visar att ZFS misslyckats isåfall?

Angående att "ZFS måste köra på hårdvara som implementerar skrivcachen korrekt". Det är inte det jag skrivit. Jag skrev att det kan bli problem att köra ZFS virtuellt eftersom VirtualBox inte implementerade skriv cachen korrekt i en länk. Det är alltså vid virtuell körning som problemet uppstår. Du måste ange en flagga så att VB behandlar skriv cachen korrekt så försvinner det problemet. Men det kanske finns andra problem i VB eller VMware? Jag försöker varna TS för att köra filservrar virtuellt. Jag säger "var försiktig, du kan få problem även fast du kör ZFS". Samtidigt som jag varnar folk för att lita obetingat på ZFS, säger du att jag försöker ge sken av att ZFS är idiotsäkert?

Citat:

[CERN] skriver att "We have 44 reported memory errors (41 ECC and 3 double bit) on ~1300 nodes during a period of about 3 month.". ~1300 noder och 3 månader är mer eller mindre ekvivalent med 3000 noder och 5 veckor.

Som du själv har sagt så kan varken ZFS (eller något annat filsystem för den delen) eller hårdvaru-RAID skydda mot dessa fel.

Vi har då som bäst att ZFS får 3 fel vs 500

Jag vet inte om jag håller med dig. ZFS skriver ned datat som finns i minnet på ett korrekt sätt ned på disk. Om datat är korruptat i minnet pga man inte kör ECC, så är det då ZFS fel? ZFS skriver ju ned datat i RAM helt korrekt ned på disk. ZFS får ett paket med data, ZFS skriver ned det paketet korrekt på disk. Hur ska ZFS veta vad som var rätt data i paketet från början? Det är faktiskt själva programmets uppgift anser jag. Det är bara programmet (t.ex. en C-kompilator, photoshop, etc) som lämnade ifrån sig datat som ska skrivas ned på disk, som kan veta hur det korrekta datat är. ZFS kan inte veta det, annat än om du byggde in en c-kompilator, och du byggde in photoshop, etc i ZFS, som kan skanna igenom datat efter felaktigheter innan det skrivs ned på disk. Du kan inte begära att ZFS ska kunna korrigera felaktiga data som den får, tycker jag. Därför håller jag inte med dig. Det ZFS får, hamnar helt korrekt på disken. ZFS håller vad det lovar. Och ZFS skulle inte gett några fel alls enligt ditt resonemang.

Citat:

"ZFS endast är till för att skydda mot firmware problem" - Skilj på "endast" och "främst". Läs denna länk igen: http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data

Det låter som att du menar att ZFS skyddar främst mot firmware problem, och all annan felhantering är inte ZFS designad för.

Citat:

Ja, man blir trött för mindre eftersom du envisas med att höja ZFS upp till skyarna.

Du kanske läste de akademiska forskningsartiklarna jag länkade till? En där ext4, XFS, NTFS etc gås igenom och alla har seriösa problem. Och en annan artikel där ZFS detekterade alla felen som forskarna kunde komma på? ZFS lyckades inte korrigera alla felen dock, eftersom forskarna inte körde raid. De körde single disk. Så om nu ZFS lyckades detektera (och skulle korrigerat om man kört raid) alla felen, så fick ZFS 100% rätt. 10 av 10. Full pott. Är inte det skäl för att säga att ZFS ger det bästa skyddet, bättre än ext3, XFS, ReiserFS och de andra?

Citat:

Jag tycker att du har allvarliga brister på teori-fronten här. Det är en matematisk omöjlighet att en enda flippad bit skapar ett sådant bit-mönster att det t.ex. slinker igenom Reed-Solomon koder (som typiskt används i hårddiskar). Det är också en matematisk omöjlighet att bit-flippar paserar en 32/64-bitars CRC kontroll om antalet bitar som flippas är färre än 32/64.

Snälla, lägg ned detta. För det första har jag läst långt mycket mer teori än dig, min specialisering på KTH var teoretisk datalogi och diskret matematik, och nu slutför jag en andra examen i matematik på universitetets matematiska institution. För det andra har du antagligen inte en aning om Abstrakt Algebra och felkorrigeringskoder. Så skippa inlägg om "matematisk omöjlighet" och såna formuleringar, det är mitt område. Jag skulle lätt kunna ställa frågor om matematiken som du inte kan svara på.

Citat:

Vad visas där? Jo; CERN använder sig av SATA diskar (högst troligen för att bespara pengar med tanke på hur mycket diskutrymme de behöver). Låter det som en ordentlig server-lösning?

Ja, det gör det? SUNs Enterprise lagringslösningar kör massor av billiga SATA diskar med ZFS i botten. Och alla torde anse att SUNs lagringsmaskiner är riktig Enterprise?

Citat:

Jag erkänner att jag verkar ha överskattat SATA diskarnas förmåga att detektera fel genom att ta funktionalitet som jag vet existerar på SAS-diskar och sedan blandat ihop dem med de som finns på SATA-diskar.

Bra. Äntligen förstår du. Det visar att du inte FUDar i alla fall.

Citat:

Men det gör CERNs konfiguration ännu mindre representativ för vad man kan få med hårdvaru-RAID på enterprise-nivå.

Rent allmänt sägs att en vanlig konsument disk får ett irreparibelt fel per 10^15 bitar. Det är även allmän konsensus att en dyr Enterprise disk får ett irreparibelt fel per 10^16 bitar. Dvs Enterprise diskar är 10 ggr "säkrare". Mao, Enterprise diskar lider av precis samma problem som vanliga SATA diskar, bara det att felen inträffar ca 10 ggr mer sällan. Mao, som CERN säger "dataintegritetsproblem hittas även på mycket dyra Enterprise lagringslösningar, oavsett pris"

Citat:

När systemet väl ha testkörts i någon månad utan problem så är en hårdvaru-RAID lösning av enterprise nivå inte avsevärt sämre än det man får med ZFS; d.v.s. ingen av lösningarna förväntas ge korrupt data.

Men likväl ger andra dyra Enterprise lösningar silent corruption. Enligt CERN och andra källor.

Citat:

SUN har länge förespråkat att man ska/kan använda sig av billiga hårdvaru-lösningar med en ordentlig mjukvaru-lösning istället för vice versa. Det blir då beskymmersamt att folk får dataförluster efter att ha följt detta "tips".

Jag har hört att när SUN pratar om "billiga lösningar" så menar de vanliga SATA diskar, och inte SAS diskar och dyra kontrollerkort som kostar lika mycket som hela min ZFS server. SUNs säljer inga servrar utan ECC minne, och ECC får väl inte anses som dyrt? Så kör du vanliga shyssta SATA diskar (dvs inte det billigaste billigaste som finns) som följer standarder och vanligt ECC minne med ZFS så får du den säkerhet som SUN pratar om.

Citat:

Betyder det att ZFS inte längre duger till budget-medvetet folk? Nej; det finns fortfarande inget alternativ som är bättre. Men vad man måste göra här är att kanske överväga att inaktivera skriv-cachen eller acceptera den lilla risken medan man väntar på att SUN gör ZFS ännu mer robust.

Ja, inaktivera skriv cachen gäller om du kör ZFS virtuellt. Som jag sa till TS, var försiktig med att köra virtuellt. Jag skulle inte göra det, trots ZFS säkerhet.

Min nästa filserver ska jag köra med ZFS och SATA diskar samt ECC minne. Nu har jag inte ECC. ECC verkar viktigt enligt forskare.

Om man kör ZFS tillsammans med ett hårdvaruraid kort så kan inte ZFS göra sin magi. Då har man tappat mycket av ZFS säkerhet. Hårdvaruraid ska undvikas tillsammans med ZFS.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam

Snälla, lägg ned detta. För det första har jag läst långt mycket mer teori än dig, min specialisering på KTH var teoretisk datalogi och diskret matematik, och nu slutför jag en andra examen i matematik på universitetets matematiska institution. För det andra har du antagligen inte en aning om Abstrakt Algebra och felkorrigeringskoder. Så skippa inlägg om "matematisk omöjlighet" och såna formuleringar, det är mitt område. Jag skulle lätt kunna ställa frågor om matematiken som du inte kan svara på.

Det där svaret förstörde ju större delen av din trovärdighet iaf. Svara direkt på hans påståenden med fakta och resonemang eller svara inte alls.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av MarcusW
Det där svaret förstörde ju större delen av din trovärdighet iaf. Svara direkt på hans påståenden med fakta och resonemang eller svara inte alls.

Ja, antingen hittar jag på eller så talar jag sanning om det. Min KTH professor sade att mitt exjobb var ett av de mest teoretiska som gjorts på datainstitutionen.

Jag försöker stänga ned denna gren om matte, då diskussion med Weeblie tenderar att spreta och grena ut massor. De blir bara större och större. Råkar man nämna t.ex. att jag läst av en analytiker i samband med Oracles köp, att SUN har högst andel forskare i Silicon Valley (för att argumentera för att SUN har mycket kompetent folk) - så genererar det omedelbart ett sidospår då Weeblie börjar diskutera sånt, t.ex. att Microsoft bara anställer programmerare med forskarexamen så jag har fel eftersom MS med alla sina programmerare har antagligen högre andel forskare än SUN. Men det stämde inte alls att MS bara anställer programmerare med doktorsexamen (vilket vore märkligt), det krävdes dock tidsödande googling. Först försökte jag googla efter MS årsrapporter med anställda och andra rapporter om deras personalsammansättning, och om MS forskningscenter och läste flera såna artiklar. Senare kom jag på att att googla MS jobbannonser och då kunde jag äntligen visa att MS anställer även vanliga B.Sc och inte endast forskare. Men detta tog tid.

Vad man än nämner så leder det till en förgrening och det tar bara längre och längre tid att besvara hans inlägg. Jag har lärt mig nu efter flera diskussioner med Weeblie, att det bästa man kan göra är att stänga ned sidospår fort som fan, innan det spårar ur. Annars får man ha lite tålamod och googla fram länkar för att visa att han missförstått nåt. Det tar sin tid dock.

Det som är bra dock, är att han fattar när han har tidigare missförstått något och erkänner att det var ett missförstånd. Det är faktiskt väldigt ovanligt, de flesta kan inte erkänna att de inte var pålästa, just då. Det går prestige och de kan inte backa (jag själv har vissa tendenser till det). Det erkännandet måste man ge honom. Det visar att han inte FUDar eller är oresonlig. Men det tar sån tid att googla fram länkar som visar att nån missförstått nånting. Men om nån postar negativa saker om ZFS, som inte bygger på rena missuppfattningar så är det bara bra tycker jag. T.ex. var det nån som påstod att ZFS kräver minst flera GB RAM. Det är ju fel, och jag fick googla mycket innan han förstod att det var en missuppfattning som kom från FreeBSDs tidiga ZFS port (som hade en minnesläcka).

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
[B]Ja, antingen hittar jag på eller så talar jag sanning om det. Min KTH professor sade att mitt exjobb var ett av de mest teoretiska som gjorts på datainstitutionen.

Att ditt exjobb var det mest teoretiska betyder inte att det var det bästa, eller ens att det var bra. Nu betvivlar jag inte att det var det, men det måste framhållas att dessa två uttalanden inte är ekvivalenta.

Sedan är ju felkorrigeringskoder relativt enkla i teorin. Det handlar om att skapa mönster där allting som är rätt är tillräckligt långt ifrån det som är fel för att kunna se när det är fel. Sedan kan man göra argumentationen tillräckligt svår och invecklad för att enbart de som verkligen är insatta i ämnet förstår något. Men enligt min erfarenhet är det de som INTE kan förklara saker i lättförståliga termer som är de som har sämst grepp om teorin. Om du kör med en vanliga odd/even-paritet kan du detektera förekomster av enstaka flippningar. Du kommer att kunna detektera alla sådana fel. När wibble säger att det är en omöjlighet att en enda bit slinger igenom stämmer det, det är teoretiskt omöjligt. Det betyder däremot inte att det är praktiskt omöjligt, eftersom någon måste implementera checksumman, och där kan det gärna bli fel. Innan du blir högljud, kaxig och för att vara ärlig ganska dryg borde du läsa, och framförallt förstå, det de andra skriver innan du klankar ner på dem.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av mix_room
Om du kör med en vanliga odd/even-paritet kan du detektera förekomster av enstaka flippningar. Du kommer att kunna detektera alla sådana fel. När wibble säger att det är en omöjlighet att en enda bit slinger igenom stämmer det, det är teoretiskt omöjligt. Det betyder däremot inte att det är praktiskt omöjligt, eftersom någon måste implementera checksumman, och där kan det gärna bli fel.

Man tackar för att det finns någon som styrker ens påstående.

Citat:

Ursprungligen inskrivet av saddam
Snälla, lägg ned detta. För det första har jag läst långt mycket mer teori än dig, min specialisering på KTH var teoretisk datalogi och diskret matematik, och nu slutför jag en andra examen i matematik på universitetets matematiska institution.

Jag vill först gratulera till din andra (master?) examen. Det är få idag som bemödar sig att ta denna möjlighet, även om jobbutsikterna efteråt onekligen ser bättre ut med dubbla examen.

Men sedan vill jag poängtera att vad för sorts utbildning du eller jag har egentligen saknar relevans. Att jag är teknisk fysiker har ingen som helst påverkan på om dem matematiska påstående som har jag givit är sanna eller falska. Inte ens mina tävlingsmeriter inom matematik är relevanta (och ja, jag kan lova dig att jag har exceptionella sådana, även om jag inte slänger dem i ansiktet på folk).

Citat:

Ursprungligen inskrivet av saddam
För det andra har du antagligen inte en aning om Abstrakt Algebra och felkorrigeringskoder. Så skippa inlägg om "matematisk omöjlighet" och såna formuleringar, det är mitt område.

Galoiskroppar tas upp på grundläggande diskret matematik och algebra kurser. Man kan knappast påstå att jag har avancerade kunskaper inom detta ämne; men för att förstå koncepten bakom Reed-Solomon och CRC koder så behöver man inte det heller.

Det är omöjligt att en enkel bit flippar på hårddisken och att det varken upptäcks av Reed-Solomon eller CRC koder. - Bestrider du det påståendet eller bestrider du inte det? Eftersom du så aktivt angrep mitt påstående så vill jag ha ett ja eller nej svar här.

Citat:

Ursprungligen inskrivet av saddam
Jag skulle lätt kunna ställa frågor om matematiken som du inte kan svara på.

Med tanke på dina utbildningars inriktningar så är du säkert också medveten om att en sådan "duell" är fullständigt meningslös annat än att försöka boosta sitt eget ego.

Citat:

Ursprungligen inskrivet av saddam
Vad man än nämner så leder det till en förgrening och det tar bara längre och längre tid att besvara hans inlägg. Jag har lärt mig nu efter flera diskussioner med Weeblie, att det bästa man kan göra är att stänga ned sidospår fort som fan, innan det spårar ur. Annars får man ha lite tålamod och googla fram länkar för att visa att han missförstått nåt. Det tar sin tid dock.

Om du inte vill att diskussionen ska grena ut sig så bör du inte heller ta med sidospår.

Jag har för vana att unvika att "selektivt" svara på någon post i en argumentation (förutom för denna post).

Du har t.ex. dragit in en rapport där forskare aktivt har "korrumperat" block i filsystem. Jag måste då ställa frågan vad det har för relevans när man jämför RAID-Z med RAID-5/6? Andra filsystem (förutom btrfs) är inte byggda för att fixa datakorruption av denna skala; de litar på att de underliggande diskarna/RAID-kontrollerna tar hand om integritetskraven. Att komma med uttryck som "ZFS 100% rätt. 10 av 10. Full pott." är strikt talat korrekt, men ack så likt något som man förväntar sig från en telefonförsäljare (som inte heller bryr sig om att man jämför äpplen med päron). Det ger, enligt min och enbart min egen åsikt, knappast ett objektivt intryck.

Jag spenderar också mycket tid på att korrigera dina missförstånd. Tror du t.ex. fortfarande att BER är ekvivalent med "Bit-rot Rate", d.v.s. att BER syftar på hur ofta en disk returnerar en trasig bit och att disken är oförmögen att istället rapportera ett CRC-fel?

Citat:

Ursprungligen inskrivet av saddam
Lite mer CERN studier:
http://indico.cern.ch/getFile.py/access?contribId=3&sessionId...
"The RAID controllers don’t check the ‘parity’ when reading data from RAID 5
file systems. In principle the RAID controller should report problems on the disk
level to the OS, but this seems not always to be the case."

Jag vet inte om du medvetet ignonerar det andra skriver eller ej, men...

Ja, vi vet att varken RAID-5 eller RAID-6 kontrollerar pariteten förutom om någon av diskarna har rapporterat in ett S.M.A.R.T.-fel och arrayen körs i degraderat läge. Det är huvudanledningen till varför RAID-5/6 tidigare rapporterade att ha högre IOPS än ZFS (d.v.s. utan L2ARC).

Men det många enterprise SAS kontrollers gör är att, som jag tidigare nämnde, formatera SAS-diskarna till att använda 520/528 istället för 512 byte block och sedan spara extra metadata där. Detta är ett extra skydd utöver felkorrigeringskoder och checksummor som används internt av diskarna, och eliminerar i princip också alla "klassiska" problem med RAID-5/RAID-6 som i andra fall inte skulle ha upptäckts av dem individuella diskarna.

CERN använder uppenbarligen inte sådan utrustning. Använd därför inte heller CERNs rapport för att dissa all hårdvaru-RAID användning.

När det kommer till kritan så är egentligen allt vi har sagt nästan helt irrelevant. Använder man Solaris så kör man ZFS (och i viss mån också om man använder FreeBSD).

Annars är ZFS inte ens ett alternativ. CDDL är enligt min åsikt ZFS's akilleshäl och orsaken till varför jag tror att btrfs för eller senare kommer att vinna detta filsystemskrig på *nix-fronten. Utan integration i Linux eller Windows så kommer ZFS att bli lika anonymt som UFS för gemene man

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Weeblie
Man tackar för att det finns någon som styrker ens påstående.

Det är ju inte mycket att tacka för. Har man rätt så har man. Däremot kommer det ju inte att gå att korrigera dessa fel. Men

Citat:

även om jobbutsikterna efteråt onekligen ser bättre ut med dubbla examen.

Det betvivlar jag faktiskt, men den diskussionen hör verkligen inte hit.

Citat:

Det är omöjligt att en enkel bit flippar på hårddisken och att det varken upptäcks av Reed-Solomon eller CRC koder. - Bestrider du det påståendet eller bestrider du inte det?

Jag skulle vilja bestrida uttrycket 'omöjligt'. Implementeringsfel gör att det mycket väl kan hända, men det borde inte hända. Med en korrekt implementering är det ömöjligt.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Jag vill först gratulera till din andra (master?) examen. Det är få idag som bemödar sig att ta denna möjlighet, även om jobbutsikterna efteråt onekligen ser bättre ut med dubbla examen.

Det är ingen Master. Det är en magister, dvs 4 år matematikstudier till, utöver civ.ing. Men tack ändå.

Citat:

Men sedan vill jag poängtera att vad för sorts utbildning du eller jag har egentligen saknar relevans. Att jag är teknisk fysiker har ingen som helst påverkan på om dem matematiska påstående som har jag givit är sanna eller falska. Inte ens mina tävlingsmeriter inom matematik är relevanta (och ja, jag kan lova dig att jag har exceptionella sådana, även om jag inte slänger dem i ansiktet på folk).

Det saknar inte relevans eftersom du svänger dig med uttryck som matematiker använder "det är matematiskt omöjligt att..." och samtidigt säger du att jag inte förstår mig på teori. Jag har bett om att få slippa höra sånt.

Matematiker tänker på ett visst sätt. De uttrycker sig på ett visst sätt. Jag kände en snubbe som gjorde de första univ mattekurser i gymnasiet. Första året på universitet skaffade han ett intyg att han fick söka till flera kurser än normalt, och läste 40p matte, 40p logik och 40 filosofi - dvs 3 års heltidsstudier. Han tog 96p det första året, tror jag. Men mesta av tiden hängde han på cafeer, han pluggade aldrig. I gymnasiet fick han en vikarie, och första dagen gick han fram till henne och sade förundrat
-Du använder ordet "måste" på ett korrekt sätt?
Hon begrep ingenting, men jag begriper. Matematiker säger aldrig ord som "måste" eller "matematiskt omöjligt" eller nåt sånt, utan vidare. Det är tunga formuleringar och matematiker undviker sånt. T.ex. undviker de att uttrycka sig som du gör:

"Jag har skrivit om och om igen att odetekterbara bit-flippar inte kan ske på moderna hårddiskar, så länge som det inte finns någon form av tillverkningsfel (t.ex. firmware buggar).

Du har inte pekat på en enda källa som pekar på motsatsen. Orsaken är enkel: det är en matematisk omöjlighet att ha ett bit-mönster med en flippad bit och som inte kan detekteras av varken felkorrigeringskoderna och checksummorna."

Simon Singh, forskare i partikelfysik har skrivit en bok som heter "Fermats Gåta". I den boken skriver fysikern så här (direkt ur boken):
"Matematik är kanske den renaste formen av tänkande, och matematikerna kan för den oinitierade framstå som marsmänniskor. Då jag samtalade med dem slog det mig varje gång hur utomordentligt precist de uttryckte sig. Mycket sällan besvarade de en fråga omedelbart. Jag brukade få vänta medan de tyst utarbetade ett noggrant strutkturerat svar. Men så kom det: precisa och välformulerade utlåtanden som inte lämnade något övrigt att önska. När jag försökte pumpa Peter Sarnak på en förklaring till detta, sade han att matematiker helt enkelt tycker direkt illa om att göra falska påståenden. Formella påståenden måste gälla oinsktränkt. Bevisföringen är själva hjärtat och själen i matematiken, något som skiljer den från andra vetenskaper."

Och du varken tänker eller uttrycker dig som en matematiker, speciellt illa blir det när du näst intill motsäger dig själv. Motsägelser är antagligen det värsta som finns inom matematiken. Men detta förklaras av att du läst teknisk fysik, och inte matematik. Så återigen, snälla skippa såna där matematiska uttryck. Det kryper nästan i mig. Och speciellt får du gärna sluta skriva att jag inte förstår mig på teori, och liknande formuleringar. När du påstår att jag har problem med teori blir det lite för mycket tycker jag. Speciellt som du inte riktigt har koll på sånt själv, vilket märks när du t.ex. kommer med svepande generaliseringar utan att kunna backa upp dina påståenden. Rena påhitt, skulle en del säga.

Citat:

Det är omöjligt att en enkel bit flippar på hårddisken och att det varken upptäcks av Reed-Solomon eller CRC koder. - Bestrider du det påståendet eller bestrider du inte det? Eftersom du så aktivt angrep mitt påstående så vill jag ha ett ja eller nej svar här.

Jisses. Men så bevisa ditt påstående då. Jag vill se ett bevis, du kan för farao inte uttrycka dig så kraftfullt utan att ha ordentligt på fötterna. Sätt igång med beviset. Eller i alla fall en bevisskiss.

Citat:

Om du inte vill att diskussionen ska grena ut sig så bör du inte heller ta med sidospår.

När man diskuterar något så är det bra om man får åberopa argument av de olika slag. Om man diskuterar t.ex. människors ondska så kanske man vill ge ett belysande exempel t.ex. Hitler (vilket omedelbart skulle rendera ett massivt sidospår eftersom jag skulle antagligen någon gång råkat nämna andra världskriget). Jag vet inte många diskussioner där man aldrig pratar om närliggande saker, du själv gör ju det när du t.ex. drar in Reed-Solomon i en diskussion om ZFS.

Och jag tar inte ditt exempel och gör ett helt sidospår av Reed-Solomon, den taktik som du använder mot andra så de tröttnar och lämnar diskussionen. Men det har du kanske förstått nu, att mot mig funkar inte din utnötningstaktik. Jag får helt enkelt visa lite tålamod och stänga till varje sidospår som du öppnar, med länkar och argumentering. Det tar sin tid dock, men jag är villig att göra det, som förrut. Så vad sägs om att jag använder exakt samma taktik som du använder mot andra, mot dig själv?

Citat:

Med tanke på dina utbildningars inriktningar så är du säkert också medveten om att en sådan "duell" är fullständigt meningslös annat än att försöka boosta sitt eget ego.

Du brukar själv inte försöka stänga ned sidospår, tvärtom brukar du öppna upp så mycket som möjligt. Eftersom du försöker stänga ned detta sidospår, så låt oss diskutera detta nu i detalj och öppna upp detta sidospår fullständigt. Jag älskar matematik och kan diskutera det i timmar på fester speciellt när jag är lite berusad. Så eftersom vi nu är inne på matematik och sånt, så kan jag fråga dig, vad gjorde du exjobb i för specialisering? Det var helt klart inte matematik. Vad kan du om högre matematik? Vilka högre kurser har du läst? Har du bara läst matte baskurserna i teknisk fysik? Var läste du? Linköping?

Citat:

Jag har för vana att unvika att "selektivt" svara på någon post i en argumentation (förutom för denna post).

Men jag förstår att du pratar om exempel och jag gör inte ett helt sidospår av ditt exempel, som du gör mot andra.

Citat:

Du har t.ex. dragit in en rapport där forskare aktivt har "korrumperat" block i filsystem. Jag måste då ställa frågan vad det har för relevans när man jämför RAID-Z med RAID-5/6? Andra filsystem (förutom btrfs) är inte byggda för att fixa datakorruption av denna skala; de litar på att de underliggande diskarna/RAID-kontrollerna tar hand om integritetskraven.

Med den rapporten försöker jag visa att andra lösningar än ZFS kan orsaka silent corruption. Du säger själv här att andra filsystem har problem om hårdvaran skulle svika. T.ex. kan hårddiskarna råka ut för bitröta, där datat blir sämre med tiden och bitarna flippas av sig själva, efter en tid. Så hur säkert är då RAID-5/6? Inte vidare enligt mig.

Citat:

Att komma med uttryck som "ZFS 100% rätt. 10 av 10. Full pott." är strikt talat korrekt, men ack så likt något som man förväntar sig från en telefonförsäljare (som inte heller bryr sig om att man jämför äpplen med päron). Det ger, enligt min och enbart min egen åsikt, knappast ett objektivt intryck.

Visst, jag kan omformulera mig om du önskar. Men forskarna försökte korrumpera ZFS, och ZFS detekterade alla försök. Så i 100% av fallen så lyckades ZFS detektera allt. Medan de andra filsystem inte klarar av att detektera alla fel, utan litar på hårdvaran. Och hårdvara kan svika som vi sett exempel på. Det är naivt att tro att hårdvara inte kan svika, det hoppas jag du håller med mig om?

Citat:

Jag spenderar också mycket tid på att korrigera dina missförstånd. Tror du t.ex. fortfarande att BER är ekvivalent med "Bit-rot Rate", d.v.s. att BER syftar på hur ofta en disk returnerar en trasig bit och att disken är oförmögen att istället rapportera ett CRC-fel?

Vad har jag för missuppfattning här? Kan du förklara och peka ut mitt fel?

Citat:

Ja, vi vet att varken RAID-5 eller RAID-6 kontrollerar pariteten förutom om någon av diskarna har rapporterat in ett S.M.A.R.T.-fel och arrayen körs i degraderat läge. Det är huvudanledningen till varför RAID-5/6 tidigare rapporterade att ha högre IOPS än ZFS (d.v.s. utan L2ARC).

Men som SMART är ju inte vidare tillförlitligt som Googles undersökning visade. Om RAID-5/6 beror av det otillförligtliga SMART, så borde väl RAID-5/6 vara icke tillförligtligt?

Citat:

Men det många enterprise SAS kontrollers gör är att, som jag tidigare nämnde, formatera SAS-diskarna till att använda 520/528 istället för 512 byte block och sedan spara extra metadata där. Detta är ett extra skydd utöver felkorrigeringskoder och checksummor som används internt av diskarna, och eliminerar i princip också alla "klassiska" problem med RAID-5/RAID-6 som i andra fall inte skulle ha upptäckts av dem individuella diskarna.

Så du menar att med 8 eller 16 byte extra stora block så är nu datat helt säkert? Skämtar du?

Citat:

CERN använder uppenbarligen inte sådan utrustning. Använd därför inte heller CERNs rapport för att dissa all hårdvaru-RAID användning.

Hur vet du att CERN inte använder sådan utrustning? Googlade du? Eller resonerade du? Jag dissar inte all hårdvaru raid användning. Det kanske finns nån extra special super duper variant nånstans som är lika säker som ZFS, eller t.om. ännu säkrare. Jag dissar all vanlig h/w raid.

Citat:

Ursprungligen inskrivet av Weeblie
Annars är ZFS inte ens ett alternativ. CDDL är enligt min åsikt ZFS's akilleshäl och orsaken till varför jag tror att btrfs för eller senare kommer att vinna detta filsystemskrig på *nix-fronten. Utan integration i Linux eller Windows så kommer ZFS att bli lika anonymt som UFS för gemene man

Enligt CERN så är ZFS det enda alternativet då CERN skriver att dataintegritetsproblem hittas även på mycket dyra Enterprise lösningar (som antagligen både har 8 och 16 bytes extra stora block).

Angående btrfs, så undrar jag hur pass bra det skyddet är. Att få till ett helt vattentätt skydd är mycket svårt, och SUN har lagt ned många års forskning och utveckling på detta, och SUNs ingenjörer har massiv erfarenhet av Enterprise lagring. Hur många års erfarenhet har btrfs killen/killarna? Jag är skeptisk och vill se innan jag tror på btrfs. Att bara lägga till lite checksummor här och där duger inte, för annars skulle man aldrig se silent corruption - men det gör man ju vilket många undersökningar visar. T.ex. visade jag att en switch var felaktig och därför korruptades datat - och ZFS upptäckte det. Mot liknande fel skulle aldrig lösningar som bara kontrollerar om disken lagrade rätt lyckas hitta felen, man måste kontrollera hela kedjan - från RAM ned till disk. ZFS kontrollerar att hela kedjan är korrekt. Om man har uppdelat, så varje lager kontrollerar sin lilla del, så kan det bli problem - därför att hårdvara kan svika. Hårdvara är aldrig ofelbar. Så om man lägger all checksumma på en disk med 8 bytes extra, så kan datat fortfarande bli korrumperat. Checksummorna måste kontrollera uppåt och nedåt, dvs hela kedjan. Inte bara en del.

CERNs data är bevisligen korrumperade, utifrån det drar du slutsatsen att h/w raid är säkert?

EDIT: litet förtydligande av obegriplig mening då ord fallit bort

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam

Jisses. Men så bevisa ditt påstående då. Jag vill se ett bevis, du kan för farao inte uttrycka dig så kraftfullt utan att ha ordentligt på fötterna. Sätt igång med beviset. Eller i alla fall en bevisskiss.

Kan du inte svara på hans fråga istället så att diskussionen kan gå framåt? :S

Permalänk
Medlem

Låt mig här "pausa" diskussionen och endast fokusera på en enda punkt.

Citat:

Ursprungligen inskrivet av saddam
Jisses. Men så bevisa ditt påstående då. Jag vill se ett bevis, du kan för farao inte uttrycka dig så kraftfullt utan att ha ordentligt på fötterna. Sätt igång med beviset. Eller i alla fall en bevisskiss.

Jag vill inte ödsla tid på att lägga fram ett bevis om ditt enda syfte är att på något sätt "testa" mig.

Påstår/"vet" du fortfarande, med bakgrund av din utbildning och erfarenheter inom ämnet, att en bit-sekvens med en enda flippad bit kan passera obemärkt förbi en R-S eller en CRC kontroll?

D.v.s. att om du svarar "ja" så tror du genuint på ditt svar och inte kommer med en replik i stil med "självklart visste jag det; men jag ville bara..." och att du inte blir alltför upprörd om någon kritiserar dina baskunskaper om det visar sig att ett matematiskt bevis kan presenteras och att du har fel.

Bara för att specifiera så betraktar vi algoritmerna självklart från ett rent matematiskt perspektiv och bortser från externa faktorer som finns i verkligheten, t.ex. möjligheten att implementationen är felaktig, att CPU:n är trasigt eller att någon få för sig att använda sig löjliga icke-standard [i termer av vad som praktiskt används] polynom designade för att vara värdelösa (t.ex. "x" eller "1" för CRC) bara för att visa sin poäng.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Bara för att specifiera så betraktar vi algoritmerna självklart från ett rent matematiskt perspektiv och bortser från externa faktorer som finns i verkligheten, t.ex. möjligheten att implementationen är felaktig, att CPU:n är trasigt eller att någon få för sig att använda sig löjliga icke-standard [i termer av vad som praktiskt används] polynom designade för att vara värdelösa (t.ex. "x" eller "1" för CRC) bara för att visa sin poäng.

Öh, nej, vi ska INTE bortse från externa faktorer. Jag påstår att h/w raid inte är säkert eftersom HÅRDVARAN KAN FALLERA OCH SVIKA (och jag har bevisat mitt påstående: detta kan ske, med länkar till bl.a. CERN). Du påstår att detta är omöjligt (annat än om det är tillverkningsfel på något sätt, t.ex. firmware buggar):

"Jag har skrivit om och om igen att odetekterbara bit-flippar inte kan ske på moderna hårddiskar, så länge som det inte finns någon form av tillverkningsfel (t.ex. firmware buggar)."

Och nu, helt plötsligt skiftar du bort fokus till att bara gälla algoritmteori? Exakt vad är det du försöker diskutera egentligen? Jag vill se ett bevis på ditt påstående: att odetektera bit-flippar inte kan ske på moderna hårddiskar, och jag vill även se ett bevis på ditt påstående om R-S och bitflippar. Sätt igång. Jag har bevisar ju mina påståenden. Nu får du göra samma sak. Ett tips: det är antagligen omöjligt att bevisa ditt första påstående.

Jag skriver att HÅRDVARAN KAN FALLERA OCH SVIKA oavsett hur bra teorin är tänkt ut. DETTA ÄR ETT AV SKÄLEN TILL ATT H/W RAID INTE ÄR SÄKERT. Jag skriver t.ex om bitröta:

"Kan du tänka dig ett scenario där disken skriver ned en 1:a korrekt men efteråt så råkas biten flippas pga något skäl, kanske strömspik, kosmisk strålning, whatever?"

T.ex. att en bitsträng lämnar diskens läs/skrivhuvud och det kommer en strömspik mitt under skrivningen så en bit flippas, precis omedelbart biljondels sekund innan biten hamnar på disk. Jag har pratat om detta scenario med strömspikar ganska många ggr tidigare.

Jag har gång på gång försökt säga att bitsträngen i RAM kanske inte är lagrad som en exakt kopia ned på disken, det kanske är bitflippar pga strömspik, kosmisk strålning, etc. Mot detta vänder du dig, och påstår att h/w raid är visst säkert. Jag påstår tvärtom och har bevisat detta med flera länkar, t.ex. CERN som visade att datat på deras h/w raid inte alls stämde - och ändå fortsätter du hävda h/w raidets säkerhet. Detta övergår mitt förstånd - det FINNS ju bevis på att h/w raid kan orsaka bitflippar. Du säger även att Enterprise diskar har 8/16 byte extra så de är totalsäkra mot bitflippar, mao kan de inte råka ut för strömspikar, kosmisk strålning, etc. Mycket märkligt påstående, om du frågar mig.

Så nu vill jag att du bevisar dina påståenden. Jag är skeptisk och tror dig inte. Sätt igång. Jag bevisar ju mina, så det är inte mer än rätt att du gör samma sak.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Öh, nej, vi ska INTE bortse från externa faktorer.

Bara för att vara helt glasklar: Du förnekar därmed inte att R-S eller ECC koder fångar upp alla enkel bit fel?

Kan du ge ett "Ja/Nej" svar till en sådan enkel fråga.

Citat:

Ursprungligen inskrivet av saddam
Och nu, helt plötsligt skiftar du bort fokus till att bara gälla algoritmteori? Exakt vad är det du försöker diskutera egentligen? Jag vill se ett bevis på ditt påstående: att odetektera bit-flippar inte kan ske på moderna hårddiskar, och jag vill även se ett bevis på ditt påstående om R-S och bitflippar. Sätt igång. Jag har bevisar ju mina påståenden. Nu får du göra samma sak. Ett tips: det är antagligen omöjligt att bevisa ditt första påstående.

Låt oss läsa igen vad jag skrev från början:

"En hårddisk som är korrekt byggd ska alltid kunna korrigera enkel bit-fel. Det finns inga enkel bit-fel som inte kan upptäckas av felkorrigeringen."

Med ren "common sense" så borde man ha uppfattat scenariot som:

a) Hårdvaran är korrekt byggd.
b) Mjukvaran är korrekt byggd.
c) Det skedde endast ett enda fel; att en bit flippades på disken efter att den hade skrivits ner och före att den lästes in.

-> Hårddisken upptäckte [och egentligen även korrigerade] bit-felet.

Det är ren algoritmteori i just detta scenario; Duger eller duger inte R-S alternativt ECC koder till att fånga upp/korrigera alla enkel bit fel?

Om du vill så kan jag från och med nu försöka att spika igenom alla sådana hål som jag vanligtvis tar för givet i en diskussion: D.v.s. påverkan av högre makter, kosmisk strålning som sabbar kontrollern trots att det inte nämns i scenario-texten, nätverksteknikern som spiller kaffe på servern, o.s.v.

Citat:

Ursprungligen inskrivet av saddam
Jag påstår att h/w raid inte är säkert eftersom HÅRDVARAN KAN FALLERA OCH SVIKA (och jag har bevisat mitt påstående: detta kan ske, med länkar till bl.a. CERN). Du påstår att detta är omöjligt (annat än om det är tillverkningsfel på något sätt, t.ex. firmware buggar):

"Jag har skrivit om och om igen att odetekterbara bit-flippar inte kan ske på moderna hårddiskar, så länge som det inte finns någon form av tillverkningsfel (t.ex. firmware buggar)."

Jag skriver att HÅRDVARAN KAN FALLERA OCH SVIKA oavsett hur bra teorin är tänkt ut. DETTA ÄR ETT AV SKÄLEN TILL ATT H/W RAID INTE ÄR SÄKERT. Jag skriver t.ex om bitröta:

Om du tar en hammare och hamrar på disken så sviker hårddisken också. Så ja, just detta påstående var nog skrivet för hastigt och läcker som ett såll då kontrollern på disken självklart inte "garanterar sig själv". Hårdvaran är inte idiotsäker och det är därför end-to-end protection uppskattas.

Men låt oss återigen kika på vad mitt ursprungliga påstående var: "En hårddisk som är korrekt byggd ska alltid kunna korrigera enkel bit-fel. Det finns inga enkel bit-fel som inte kan upptäckas av felkorrigeringen."

Om du vill vara riktigt petig så stämmer det att jag inte skrev något om hårdvaran fallerade eller ej. Men om du vill ta med sådana situationer så kan vi ur CERN:s rapport utläsa att HÅRDVARAN (ECC RAM) HAR I VISSA FALL FALLERAT OCH SVIKIT PÅ ETT SÅDANT SÄTT SOM INTE ENS ZFS KAN GARANTERA INTEGRITETEN PÅ.

Citat:

Ursprungligen inskrivet av saddam
"Kan du tänka dig ett scenario där disken skriver ned en 1:a korrekt men efteråt så råkas biten flippas pga något skäl, kanske strömspik, kosmisk strålning, whatever?"

T.ex. att en bitsträng lämnar diskens läs/skrivhuvud och det kommer en strömspik mitt under skrivningen så en bit flippas, precis omedelbart biljondels sekund innan biten hamnar på disk. Jag har pratat om detta scenario med strömspikar ganska många ggr tidigare.

Ja, och felet kommer då att plockas upp och korrigeras vid inläsning.

Detta är exakt följande scenario:

a) Hårddisken är korrekt byggd och har inga konstruktionsfel.
b) Mjukvaran är korrekt.
c) Det skedde endast ett enda fel; att en bit flippades på disken efter att den hade skrivits ner och före att den lästes in [p.g.a. strömspiken].

Citat:

Ursprungligen inskrivet av saddam
Jag har gång på gång försökt säga att bitsträngen i RAM kanske inte är lagrad som en exakt kopia ned på disken, det kanske är bitflippar pga strömspik, kosmisk strålning, etc.

ECC och EDC finns just där för att förhindra dessa situationer.

Förhindrar de alla former av bit-flippar? Nej, självklart inte.

För att citera dig själv igen: "...att en bitsträng lämnar diskens läs/skrivhuvud och det kommer en strömspik mitt under skrivningen så en bit flippas, precis omedelbart biljondels sekund innan biten hamnar på disk..." - Detta är klart och tydligt inte alla former at bit-flippar utan ett högst specifikt fall som kommer att detekteras av ECC/EDC (så länge som det inte sker andra fel; vilket inte fanns i ditt exempel).

Citat:

Ursprungligen inskrivet av saddam
Mot detta vänder du dig, och påstår att h/w raid är visst säkert.

Ja, hårdvaru-RAID är visst säkert.

Är det felfritt? Nej.
Har RAID-5 sina egna problem, t.ex. om en disk dör och man måste bygga om arrayen? Ja. datadensiteten börjar numera bli så hög att UER säger att man bör använda sig av RAID-6. Men samma problem har ZFS med raidz1 om en disk dör helt.

Jag hade inte argumenterat emot dig om du istället för att envisas med att sprida skräck över hårdvaru-RAID hade kommit med påstående om att RAID-Z är SÄKRARE.

Citat:

Ursprungligen inskrivet av saddam
Du säger även att Enterprise diskar har 8/16 byte extra så de är totalsäkra mot bitflippar, mao kan de inte råka ut för strömspikar, kosmisk strålning, etc. Mycket märkligt påstående, om du frågar mig.

8/16 byte extra totalsäkrar* upp till (men inte inklusivt) den del av systemet som använder sig av dessa extra bytes. I detta fall RAID-kontrollern. Självklart skyddar inte RAID-kontrollern mot kosmisk strålning som drabbar ECC minnena, en EMP-puls som släcker ut processorn eller att en strömspik grillar kontrollern själv. Behöver jag nämna firmware-buggar igen?

ZFS skyddar av samma anledning inte heller mot mjukvaru-buggar i sig själv.

* = Totalsäkrar i praktisk mening, inte matematisk. ZFS 64?/256?-bitars checksumma är strikt talat inte heller helt säker.

Citat:

Ursprungligen inskrivet av saddam
Jag påstår tvärtom och har bevisat detta med flera länkar, t.ex. CERN som visade att datat på deras h/w raid inte alls stämde - och ändå fortsätter du hävda h/w raidets säkerhet. Detta övergår mitt förstånd - det FINNS ju bevis på att h/w raid kan orsaka bitflippar.

Jag vill hänvisa dig till följande blogg-post och dess kommenterarer som ironiskt nog handlar om nästan exakt samma diskussion vi har haft, och där exakt samma CERN-rapport länkades till: http://drewthaler.blogspot.com/2007/10/zfs-hater-redux.html

Kika specifikt på följande presentation som gjordes av CERN-folket, efter deras rapport:

https://indico.desy.de/getFile.py/access?contribId=65&session...

Öppna bild 9 och framåt, angående om feltyperna och deras orsaker:

- Typ 1: Usually bad memory (RAM, cache, etc.).
- Typ 2: Observed in vicinity of OOM situations. Possible SLAB corruption?
- Typ 3: Strong correlation: I/O command timeouts. 3ware hides timeouts, look at extended diag. Seems to match RAID stripe size.
- Typ 4: ...not sure yet this warrants another category.

Skyddar ZFS mot typ 1 fel? Nej, ZFS förlitar sig på att det som finns i RAM stämmer.
Skyddar ZFS mot typ 2 fel? Nej (åtminstone högst troligen inte), ZFS är inte byggt för att skydda mot minnesallokeringsfel gjorda av kärnan.
Skyddar ZFS mot typ 3 fel? Ja!

Men vad verkar typ 3 fel bero på? Jo, ej korrekt byggda raid-kontrollers.

---

Varför har jag pressat angående om R-S koder och CRC? Jo, just för att understryka att feldetektering inte är ekvivalent med felkorrigering och att det är mycket osannolikt att båda typer av kontroller passeras. Låt oss kika på en av kommentarerna i blogg-posten. Den försöker också att förklara skillnaden mellan BER/UER och riktig osynlig "bit-röta".

Citat:

The non-recoverable error rate is specified as 10^-16. This says that if you read the whole disk 8,333 times, you're likely to encounter one bad block. Not a block with incorrect data, but a block for which the disk had detected an error and reported it to the computer. If you're using a standard file system, with no mirroring, you've lost data at this point. A simple mirror would protect you, of course. (How big is 10^16 bits? If you read constantly at 50 MB/second, then after 9.5 months you would expect to encounter your first bad block.)

What the checksums in ZFS (and WAFL, incidentally, and some other file systems and database systems) protect you from is the next category of errors, those which are mis-corrected. How frequent are those? Less than 10^-16. Probably much less, on the order of 10^-18 or 10^-20, depending on the details of which error-correcting code the drive uses. At 50 MB/second, you'll see one of those after somewhere between 79 and 7900 years.

Är risken fortfarande lite väl stor? Troligen.

Men vad händer om du istället använder dig av en enterprise lösning som använder sig av 520/528 bytes block och ytterliggare en CRC32/64 kontroll ovanpå?

Permalänk
Avstängd

Alltså, vad är det vi är oense om egentligen? Kan du sammanfatta dina ståndpunkter? Så sammanfattar jag mina. Jag föreslår att vi fastslår vad vi är oense om, så kan vi diskutera kring de punkterna?

1. Jag har aldrig påstått att ZFS är 100% säkert (annars skulle jag aldrig postat länkar som visar när ZFS misslyckas), men det är säkrare än h/w raid som kan vara ganska kasst. Du verkar tro att jag säger att ZFS är 100% säkert?

2. Jag påstår att i praktiken så får du silent corruption med h/w raid, ja, med de flesta andra lösningar - även om hårdvaran är felfri när den konstruerades eller om algoritmen är teoretiskt korrekt. Du verkar tro att t.ex. om en algoritm är teoretiskt korrekt så betyder det att i praktiken kan det aldrig bli fel och störningar? Det låter märkligt, ingen tror väl det. Så vad är det vi är oense om här?

3. Jag har postat flera länkar som visar silent corruption på h/w raid, det har även du gjort. Du verkar anse att silent corruption inte kan förekomma på h/w raid, trots att du postat länkar som bevisar förekomst utav det. Kan du specificera vad vi inte är överens om här?

4. Du håller med mig om att SATA diskar inte är så säkra som du trodde. Men jag påstår att konsensus är att Enterprise diskar är 10ggr säkrare än SATA diskar, dvs de får också problem men bara 10 ggr så sällan. Menar du att SATA diskar är osäkra, men Enterprise diskar är 100% säkra eftersom de har 8/16 byte större checksummor än SATA diskar?

Har du fler punkter som vi är oense om angående ZFS vs h/w raid och om dataintegritet?

Permalänk
Medlem

Sammanfattning av mina ståndspunkter (numreringen matchar inte nödvändigtvis med din):

1) Dataintegritetsrisken med hårdvaru-RAID är mycket låg när det väl fungerar. Hårdvara har en tendens att fallera avsevärt oftare i början och i slutet av sin livscykel; inte i mitten. CERN:s studie är ett strålande exempel på vad alla bör göra i sin planerning för enterprise lagring. Budget lösningar bör man alltid undvika om dataintegritet är A och O, och en månads "tortyrtestning" är normallt sett fullt tillräckligt för att hitta de allra flesta kompabilitetsproblemen/firmwareproblemen. Exkluderar du WD:s firmware-bugg och 3ware:s kontrollers i CERN:s rapport så finns det inga klara tecken på att hårdvaru-RAID skulle vara mer problematisk än mjukvaru-RAID.

2) Med utgång från punkt 1 att hårdvaran har testats, så ska hårdvaru-RAID av enterprise kvalitet inte ge "silent corruptions". Med "inte" så menar jag här att sannolikheten inte bör överskrida sannolikheten att CPU:n eller nordbryggan är defekt och därmed påverkar all annan form av icke-klustrad lagring.

3) Du kan antingen testa hårdvaran själv (vilket man egentligen alltid bör göra ändå) eller så kan man förlita sig på att någon annan har gjort det åt en; d.v.s. genom att köpa en server med ett RAID-kort och hårddiskar som redan idag används på tiotusentals olika ställen. Om ett sådant paket fungerar för så många andra utan problem så bör det inte heller finnas några kompabilitets- eller firmware-problem kvar. Den största boven i dramat enligt CERN:s rapport har då blivit oskadligjord.

4) SAS-diskar har på pappret endast 10 gånger bättre UER än SATA-diskar, men UER är inte allt. 520/528 bytes sektorer versus 512 bytes sektorer och en tillhörande RAID-kontroller som använder dem extra byten är betydelsefull på samma sätt som att ZFS's 64/256-bitars checksumma är betydelsefull. 8/16 bytes är skillnaden mellan att upptäcka eller inte upptäcka skrivningar som sker till fel plats på disken och skrivningar som ignoneras. Sedan får man inte glömma det inte är sällan som enbart SAS-diskar har testats och certifikerats av tillverkaren på den RAID-kontroller som man vill använda. Om man väljer att använda SATA-diskar och inte testar de själv på den RAID-kontroller man vill använda så får man faktiskt skylla sig själv om kompabilitetsproblem leder till datakorruption.

5) CERN:s studie tyder på att ECC-minnen ej är tillräckliga. Den extra säkerhet man får med ZFS trumfas av dubbel och trippel (!) paritetsfel, även med ECC-minnen. Man bör prata om att använda sig av "chipkill"-liknande teknologier innan man börjar bråka om RAID-Z och ordentlig hårdvaru-RAID. (Vilket numera även finns på billigare servrar under produktnamn som "Extended/Enhanced ECC", men eftersom det är på bekostnad av mängden RAM så väljer de flesta att prioritera budgeten.)

Så vad är min egen slutsats?

Billigare hårdvara - ZFS är att föredra.
Dyrare hårdvara - Det spelar mycket mindre roll.

Datakorruptionsrisken för en enskild server når sitt lägsta värde på grund av externa faktorer långt före dem teoretiska värdena för ZFS och ordentlig hårdvaru-RAID. Bryr man sig verkligen om dataintegriteten så väljer man nog någon form av distributerad lagring (i.e. Google:s stil/"köp tio korgar ägg istället för en") som då oftast använder sig av helt propertiära filsystem.

Vad vi verkar vara oense om är exakt stor skillnaden i säkerhet det är mellan RAID-Z och hårdvaru-RAID som genom tester inte visar sig har några uppenbara problem och om hurvidda den extra säkerheten är betydelsefull i sken av andra externa faktorer.

ZFS:s styrka är IMO egentligen -inte- att vara säkrare än enterprise hårdvaru-RAID utan att man för samma "mängd" säkerhet behöver betala avsevärt mindre.

Permalänk
Medlem

Allvarligt talat grabbar, hur intressant er diskussion än må vara men när ni måste börja slänga ur er titlar från diverse utbildningar och tävlingar(!) i matte, hur fan hade ni tänkt att komma någon vart, ni har automagiskt gjort det till en akademisk kukmätartävling på rätt låg nivå för personer med så hög utbildningsgrad

Permalänk
Medlem

Det jag inte förstår är: Varför inte köra allt detta i privata meddelanden? ? ?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Pappy
Det jag inte förstår är: Varför inte köra allt detta i privata meddelanden? ? ?

Antagligen för att vi ska få ta del av deras åsikter, och kanske själva lära oss något.

Men jag vet inte o0

Permalänk
Avstängd

Ok, så låt oss se. Vi är inte överens om dessa saker, som jag förstått det?

1. Jag påstår att Silent Corruption är en realitet och förekommer i överraskande hög grad i praktiken ute bland företagen. Du påstår att det inte stämmer, Silent Corruption förekommer knappt alls, om ens någonsin i praktiken.

2. Om man köper korrekt fungerande enterprise h/w raid så slipper man silent corruption.

3. Om man har vanlig h/w raid hårdvara som funkar korrekt och man testar igenom hårdvaran så man vet att den verkligen funkar som tänkt, så är man säker. Man slipper då Silent Corruption.

4. SATA diskar är osäkert. Men Enterprise diskar är säkra pga de har 8/16 byte extrastora checksummor.

5. Du menar att inte ens ECC minne inte räcker till, och kan orsaka många problem. ZFS lagar några problem, men långt ifrån så många som ECC RAM kan ställa till med. Så det är alltså viktigare att ha bra RAM än att använda ZFS. ZFS fixar så få problem att det inte är värt att lägga krut där. Bättre lägga krut på bra RAM.

Jag har nu omformulerat dina ståndpunkter såsom jag uppfattar dem. Stämmer min tolkning?

Nidas,
Jo, men det är inte så trevligt när man tidigare blivit beskylld för att FUDa och ens kunskaper ifrågasätts och nu har jag tydligen även problem att fatta teori? Då blir det lite för mycket. Ännu en gång. Och då kanske man förstår varför jag reagerar som jag gör, när jag ber honom sluta. Jobbigt att avkrävas ens CV för att ens argument ska vara värda att lyssnas på. Om jag inte haft någon utbildning hade jag garanterat blivit avfärdad som mindre vetande och inte värd att tagas på allvar.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Ok, så låt oss se. Vi är inte överens om dessa saker, som jag förstått det?

1. Jag påstår att Silent Corruption är en realitet och förekommer i överraskande hög grad i praktiken ute bland företagen. Du påstår att det inte stämmer, Silent Corruption förekommer knappt alls, om ens någonsin i praktiken.

2. Om man köper korrekt fungerande enterprise h/w raid så slipper man silent corruption.

3. Om man har vanlig h/w raid hårdvara som funkar korrekt och man testar igenom hårdvaran så man vet att den verkligen funkar som tänkt, så är man säker. Man slipper då Silent Corruption.

4. SATA diskar är osäkert. Men Enterprise diskar är säkra pga de har 8/16 byte extrastora checksummor.

5. Du menar att inte ens ECC minne inte räcker till, och kan orsaka många problem. ZFS lagar några problem, men långt ifrån så många som ECC RAM kan ställa till med. Så det är alltså viktigare att ha bra RAM än att använda ZFS. ZFS fixar så få problem att det inte är värt att lägga krut där. Bättre lägga krut på bra RAM.

Jag har nu omformulerat dina ståndpunkter såsom jag uppfattar dem. Stämmer min tolkning?

1) Din tolkning är korrekt, om företagen i fråga använder sig av "best practice". Du behöver egentligen inte kika längre än till backup-rutinerna för att inse att många inte gör det.

2) Ja, om du med "slipper" istället menar "inte nämnvärt sannolikare än att CPU:n, nordbryggan eller någon annan vital komponent faller sönder".

3) Samma som punkt 2.

4) 8/16 byte metadata är allt som behövs för att förhindra de vanligaste hårdvaru-RAID problemen. Att det är SAS eller SATA diskar vi pratar om spelar egentligen ingen roll; men i dagsläget så är det endast SAS-kontrollers och SAS-diskar som använder/kan formateras med 520/528 byte sektorer.

5) ZFS "flaskas" av att ECC minne inte är tillräckligt. Hur många problem ZFS lagar beror på vad för sorts hårdvara man har. Tar du bort firmware-problemen som visas i CERN:s rapport så fixar ZFS inte ens en storleksordning fler fel än vad som skulle ha genererats av bit-flippar i RAM. Att du köper dyrare RAM hjälper inte här; du måste använda dig av teknologier som klarar av att en enskild sticka är helt defekt, se t.ex. Google:s rapport. Men även där slår du snabbt i taket och distributerad lagring är nödvändig för vidare säkerhet.

I princip: "Alright... låt oss sätta oss ner och titta på exakt vilka hårdvaru- respektive mjukvaru-fel ZFS inte skyddar mot. Jämför sedan med hårdvaru-RAID av hög kvalitet."

Citat:

Ursprungligen inskrivet av saddam
Nidas,
Jo, men det är inte så trevligt när man tidigare blivit beskylld för att FUDa och ens kunskaper ifrågasätts och nu har jag tydligen även problem att fatta teori? Då blir det lite för mycket. Ännu en gång. Och då kanske man förstår varför jag reagerar som jag gör, när jag ber honom sluta. Jobbigt att avkrävas ens CV för att ens argument ska vara värda att lyssnas på. Om jag inte haft någon utbildning hade jag garanterat blivit avfärdad som mindre vetande och inte värd att tagas på allvar.

Jag tycker att jag har gjort min ståndspunkt klar att det är föga intressant för mig hur fint eller fult CV den jag argumenterar emot har. Argumenten vägs endast med sina egna meriter; inte meriterna hos den talande.

Att vara den som börjar med att slänga ut sina meriter är alldeles för riskfyllt för min smak. Råkar man trots allt ha fel om sin sak så faller man bara ännu hårdare.

Permalänk
Avstängd

Vi kanske kan enas om att vanliga filsystem (utom ZFS) inte är tillräckligt säkra. Är vi överens om att vanliga filsystem som NTFS, ext3, XFS, ReiserFS, etc - alla de brister i att detektera och reparera fel? Jag har visat länkar till forskningsartiklar som visar att de filsystemen inte klarar av att detektera eller korrigera fel. Är vi överens om detta?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Vi kanske kan enas om att vanliga filsystem (utom ZFS) inte är tillräckligt säkra. Är vi överens om att vanliga filsystem som NTFS, ext3, XFS, ReiserFS, etc - alla de brister i att detektera och reparera fel? Jag har visat länkar till forskningsartiklar som visar att de filsystemen inte klarar av att detektera eller korrigera fel. Är vi överens om detta?

Det stämmer bra att vi verkar vara överens om att de andra filsystemen endast är byggda för att hantera strömavbrott (journalföring/soft updates) och inte datakorruption.

Om det är tillräckligt säkert eller ej beror till stor del på vad för krav man har. Filsystem för långtidslagring och filsystem för root-partionen på ens huvudlösa server har normallt sett helt andra krav.