Vinn nätagg från Seasonic
Forum Mjukvara Linux och övriga operativsystem Tråd Inlägg

Är hårdvaru raid på väg att dö ut?

1 2 3 4 5
Skriv svar
Permalänk
Avstängd
●
Skrivet av Arctunix:

Vet du vad skillnaden är mellan att stöta på en bugg i ett komplext filsystem som ZFS, och att stöta på design[icke]problem?

Jo, med buggar så tappar du all din data idag (Googla så får du se att det har hänt många som har använt ZFS). Med "designproblemen" som du kallar dem så har du bara möjligheten att tappa all din data... och detta bara när Jupiter, Saturnus och Pluto bildar en rät linje. Det finns en orsak till varför vissa har gått tillbaka till tried-and-true hårdvaru-RAID + UFS.

Gå till inlägget

Detta förstår jag inte alls. Menar du att när du träffar på en ZFS bug så tappar du alla dina data, det finns bara såna ZFS buggar? De enda ZFS buggar som finns, leder till att du tappar alla dina data? Och designproblem som finns i hw-raid leder till att du inte tappar alla dina data?

Har du hört talas om hw-raid, write hole error design problemet, där du tappar alla dina data i hw-raid om du drar ut strömmen mitt i, det som mats42 pratar om? Det som mats42 tror även drabbar ZFS?

Så här, visst finns det buggar i ZFS, men tror du hw-raid är buggfritt? Min kompis som är CTO på ett IT-företag berättar att han råkat ut för buggar i hw-raid firmware så han tappat alla data. Detta har hänt 3ggr med de hw-raid de köpt in. Och innan ni börjar säga att han är en amatör, så kan jag lägga till att han vet vad han sysslar med, en av de skärptaste IT personerna jag känner. Han har utmärkt sig flera ggr, varit bland de bästa i Sverige i olika programmeringstävlingar, har flera examina, varav data civ.ing är en.

Ni pratar om att folk tappat data med ZFS, visst det är sant. Men samtidigt, tror ni att folk inte tappat data med hw-raid? Jag har inte nämnt det, eftersom det är självklart. Det finns många historier om där folk tappat sina data med hw-raid. Men det pratar jag inte om eller visar länkar till. Jag är intresserade av designproblem som gör att man tappar alla sina data i hw-raid.

ZFS har en mycket säkrare design, men det finns buggar i ZFS.

hw-raid har en gammal design som är uråldrig och osäker, dessutom finns det massa buggar i hw-raid. Så man kan förlora på två sätt här, designproblem och även via buggar.

Citat:

Se, där har du svaret på din egen fråga.

Vart vill du komma? Att man ska köpa extra hårdvara som är strömsnål, hellre det än att använda den hårdvara man redan har?

Citat:

Välj mellan att antingen slå av skrivcachen och få ohyggligt dålig prestanda, eller slå på den och därmed tappa D i ACID eftersom ZFS då inte längre flushar till ett permanent lagringsmedium när transaktionssystemet säger åt den att göra det.

Ok, så hur ska du ha det? Först menade du att ZFS inte duger för ACID databaser (se nedan), och här ovan menar du att det är ett val man gör. Är det kört för ZFS eller inte om vi pratar ACID? Uppfyller ZFS kraven för ACID eller inte? Hur ska du ha det?

Citat:

Ajdå! Verkar som man i så fall inte kan använda ZFS för ACID-databaser överhuvudtaget (i.e. du tappar D-et).

Du refererar till något mats42 skriver:

Citat:

Och fortfarande är inte någon SSD lösningen på avsaknad writecache. Du gör faktiskt tom problemet värre för nu ska du först skriva till SSD, sen lässa från SSD och sen skriva till disk. Dvs du tredubblade mängden I/O som krävdes för att skicka datat till disk och du kan fortfarande inte skriva fortare till disken heller.

Jag förstår inte detta motargument till ZFS och SSD skrivcache.

När du använder hw-raid med ett journalförande filsystem, så måste du först skriva "datat som ska sparas" ned på hw-raidets journal. Journalen ligger på hw-raidets diskar. Sen läser du journalen och betar av den, och flyttar datat som ligger i journalen, ned till diskarna. Så hw-raid har precis samma problem som mats42 pratar om. Man skriver till journalen, sen läser från journalen och sen skriver ned datat.

Det ZFS gör, är att man kan lägga journalen på en mycket snabbare SSD disk. Det går snabbt att skriva ned journalen till SSD. Sen läser man snabbt från SSD och sen skriver ned det på ZFS raidet. Enda skillnaden är att ZFS har journalen på en SSD. Så diskarna utnyttjas inte lika mycket som på ett hw-raid, där både journal och data ligger.

Jag fattar inte detta motargument mot ZFS? Att separera data från journal, och placera journalen på en snabb SSD, är det dåligt?

Citat:

För att inte nämna skrivcyklerna.

Enligt SweClocker's nyhet om Intel's nästa enterprise SSD så kan den skriva upp till 500 - 1100 TB. Det tar inte längre än mellan 30 och 65 dagar att få slut på dem, trots att vi flaskar med 200 MB/s vilket är långt under medel-belastningen på relativt vanliga hårdvaru-RAID arrayer. Okay, SSD:n räcker egentligen för dubbla antalet dagar eftersom (som mats42 har påpekat) så måste även läsa upp allt som skrivs ner. 100 MB/s? Ouch!

Vad försöker du säga här? Att ZFS kör slut på SSD, men det gör inte vanlig hw-raid? När du använder hw-raid så räcker SSD mycket längre än med SSD? "Ouch"? Kan du försöka vara lite mer explicit i de slutsatser du försöker dra? Argumentera gärna, och avsluta med själva slutsatsen så slipper jag dra den själv. Därför att folk tänker olika och det som är tydligt för dig, inte nödvändigtvis är tydligt för mig.

T.ex. kan du svara istället för "där har du svaret på din egen fråga", så kan du svara "ditt svar bevisar min tes att bla.bla. förstår du nu hur jag menar?". Det blir det enklare att debattera om du återkopplar.

Citat:

ZFS ser bra ut på pappret men har väldiga praktiska prestandaproblem, tycker jag.

Att ha praktiska prestandaproblem är inget man tycker. Antingen har man det, eller inte. Jag kan posta länkar som visar att ZFS är snabbare än hw-raid. Vill du se?

Redigera
Citera flera Citera
Permalänk
Avstängd
●

mats42
Du påstår massa saker, men jag ser inga länkar. Tror du att du kan posta lite länkar till de saker du påstår? T.ex. att hw-raid skyddar mot bitröta.

Jag har postat länkar som säger att fysikcentret CERN gjorde undersökningar, de lagrar ju massa data från sina partikelacceleratorer, och såg att deras hw-raid lösningar inte skyddade mot bitröta. Tvärtom såg de ganska mycket bitröta på sina diskar. Jag hoppas att du inte menar att CERN är ett gäng amatörer som inte förstår sig på lagring? Jag tror att CERN har ganska hög kompetens?
http://storagemojo.com/2007/09/19/cerns-data-corruption-resea...

Kan du posta länkar som stödjer det du säger?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av saddam:

Och designproblem som finns i hw-raid leder till att du inte tappar alla dina data?

Gå till inlägget

Exakt. Kan du förklara för mig vilket designproblem som finns i hw-raid som gör att du tappar all data?

Skrivet av saddam:

Har du hört talas om hw-raid, write hole error design problemet, där du tappar alla dina data i hw-raid om du drar ut strömmen mitt i, det som mats42 pratar om? Det som mats42 tror även drabbar ZFS?

Gå till inlägget

Jag känner folk som arbetar på massiva datacenters och de har aldrig stött på write hole problemet.

Förklaringen är busenkel: Precis som vilken vettig person som helst så använder de RAID-kontrollers med batteri-backup.

Skrivet av saddam:

Så här, visst finns det buggar i ZFS, men tror du hw-raid är buggfritt?

Gå till inlägget

Tror du att vanliga diskkontrollers är buggfria? Speciellt om du följer "best practice" för ZFS och köper billiga* komponenter?

RAIDZ skyddar bara mot att du tappar enskilda diskar och inte hela kontrollers.

* = Jag vill egentligen argumentera emot kostnadsanalysen för ZFS. På min hemma-server så har jag själv haft enorma problem med att hitta billiga diskkontrollers med många portar och som inte är totalgimpade när det kommer till prestanda. Att köpa en vanlig RAID-kontroller och sedan köra JBOD känns inte alltför kostnadseffektivt. Kombinationen Sandy Bridge-E och X79 verkar dock vara riktigt, riktigt intressant.

Skrivet av saddam:

Han har utmärkt sig flera ggr, varit bland de bästa i Sverige i olika programmeringstävlingar...

Gå till inlägget

Heh, lustigt att du nämner programmeringstävlingar som om de har någon som helst relevans för denna diskussion. Det finns dessutom en god chans att kommentaren slår slint.

Skrivet av saddam:

Ni pratar om att folk tappat data med ZFS, visst det är sant. Men samtidigt, tror ni att folk inte tappat data med hw-raid? Jag har inte nämnt det, eftersom det är självklart. Det finns många historier om där folk tappat sina data med hw-raid. Men det pratar jag inte om eller visar länkar till.

Gå till inlägget

Det finns nog ingen som argumenterar emot att folk tappar data trots hårdvaru-RAID. Vissa har redan nämnt att RAID (i alla dess former) inte kan ersätta goda backuprutiner. Frågan du borde ställa till din vän är om han vet vad som orsakade dataförlusterna. Jag har själv kommit i direkt kontakt med både trasiga minnesmoduler och kontrollerkort som slutar att fungera efter en viss tid.

D.v.s. situationer som även skulle ha sänkt ZFS.

Skrivet av saddam:

Jag är intresserade av designproblem som gör att man tappar alla sina data i hw-raid.

Gå till inlägget

Jag är inte intresserad av teoretiska problem.

Praktiskt visar det sig att ZFS och mjukvaru-RAID har sämre prestanda för krävande användningsområden [enligt min egen erfarenhet och uppenbarligen även enligt mats42's].
Praktiskt visar det sig också att när ZFS väl failar så failar den oftast katastrofalt.

Det sista, om något, är väl ZFS's värsta "designproblem" (nåja - låt oss kalla det för "tradeoff" istället). Recovery-verktyg är så vitt jag vet i princip obefintliga för ZFS p.g.a. filsystemets komplexitet. Har man förresten ens lagt till möjligheten att ångra "zfs destroy" idag?

Skrivet av saddam:

ZFS har en mycket säkrare design, men det finns buggar i ZFS.

Gå till inlägget

Vad tror du är mest komplext och har flest rader kod, och därmed sannolikt flest buggar?

Skrivet av saddam:

Vart vill du komma? Att man ska köpa extra hårdvara som är strömsnål, hellre det än att använda den hårdvara man redan har?

Gå till inlägget

Japp. Hamna inte i en situation där allt ser ut som spikar bara för att du har en hammare. Rätt verktyg skall användas för rätt ändamål.

Bara för att man redan har hårdvaran så betyder det inte att den inte redan används. Från pris, prestanda och driftkostnads synvinkel så är det bara dumt att behöva punga ut med ännu mera pengar på maffigare processorer bara för att kunna köra mjukvaru-RAID.

Skrivet av saddam:

Ok, så hur ska du ha det? Först menade du att ZFS inte duger för ACID databaser (se nedan), och här ovan menar du att det är ett val man gör. Är det kört för ZFS eller inte om vi pratar ACID? Uppfyller ZFS kraven för ACID eller inte? Hur ska du ha det?

Gå till inlägget

Skrivcache Av = För dålig prestanda.
Skrivcache På = Garanterar ej D i ACID vid OS-krash.

Slutsats: ZFS duger inte till transaktionssystem med prestandakrav.

Skrivet av saddam:

Jag förstår inte detta motargument till ZFS och SSD skrivcache.

När du använder hw-raid med ett journalförande filsystem, så måste du först skriva "datat som ska sparas" ned på hw-raidets journal. Journalen ligger på hw-raidets diskar. Sen läser du journalen och betar av den, och flyttar datat som ligger i journalen, ned till diskarna. Så hw-raid har precis samma problem som mats42 pratar om. Man skriver till journalen, sen läser från journalen och sen skriver ned datat.

Det ZFS gör, är att man kan lägga journalen på en mycket snabbare SSD disk. Det går snabbt att skriva ned journalen till SSD. Sen läser man snabbt från SSD och sen skriver ned det på ZFS raidet. Enda skillnaden är att ZFS har journalen på en SSD. Så diskarna utnyttjas inte lika mycket som på ett hw-raid, där både journal och data ligger.

Jag fattar inte detta motargument mot ZFS? Att separera data från journal, och placera journalen på en snabb SSD, är det dåligt?

Gå till inlägget

Nej, det är inte så journalförande filsystem vanligtvis fungerar.

1) Du behöver inte läsa upp journalen från disk igen eftersom samma information redan finns i minnet.
2) Det är bara metadata som skrivs till journalen.

Databas-applikationer brukar dessutom förallokera uttrymme på disken vilket gör att filsystems-journalen inte involveras överhuvudtaget under normala operationer.

ZFS är annorlunda då ZIL verkligen är en skrivcache.

Skrivet av saddam:

Vad försöker du säga här? Att ZFS kör slut på SSD, men det gör inte vanlig hw-raid? När du använder hw-raid så räcker SSD mycket längre än med SSD? "Ouch"? Kan du försöka vara lite mer explicit i de slutsatser du försöker dra? Argumentera gärna, och avsluta med själva slutsatsen så slipper jag dra den själv. Därför att folk tänker olika och det som är tydligt för dig, inte nödvändigtvis är tydligt för mig.

Gå till inlägget

Varför börjar du helst plösligt prata om hårdvaru-RAID med SSD:n? Nåja, låt oss lägga till det scenariot också:

1) RAID-6 med 18st SSD:n vs RAIDZ2 med 18st SSD:n.
2) RAID-6 med 18st mekaniska diskar vs RAIDZ2 med 18st mekaniska diskar och 1st/2st SSD:n för ZIL.
3) RAID-6 med 18st mekaniska diskar vs RAIDZ2 med 18st mekaniska diskar

Dessa ger oss följande resultat:

1) Hårdvaru-RAID har 16 gånger fler IOPS än ZFS.
2) SSD:n är en single-point-of-failure. SSD:n flaskar skrivningar. Skrivcyklerna gör att du måste byta ut SSD:n en gång per två månader även om du bara skriver med 200 MB/s till arrayen.
3) Hårdvaru-RAID har 16 gånger fler IOPS än ZFS.

Är det tydligt nog för dig?

Skrivet av saddam:

Att ha praktiska prestandaproblem är inget man tycker. Antingen har man det, eller inte. Jag kan posta länkar som visar att ZFS är snabbare än hw-raid. Vill du se?

Gå till inlägget

Jag citerar: "Då förlorar du senaste ändringarna iofs, som kan sträcka sig ända upp till 30sekunder. Det är ett litet problem dock, tycker jag."

Att ha praktiska problem med att tappa 30 sekunder är inget man tycker. Antingen har man det, eller inte. Låt oss inte kasta sten i glashus.

ps. Jag vill gärna se länkar där ZFS är snabbare än hårdvaru-RAID och där man:

1) Har slagit av skrivcache eftersom jag finner det oacceptabelt att tappa 30 sekunder.
2) Kommit upp till 500+ MB/s (sustained) hastigheter med en blandning av slump-läs och sekventiell-läs/skriv belastning på ett dataset som sträcker sig över 10 TB.
3) Inte betalat multum för systemet.

Senast redigerat
Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av Arctunix:

Exakt. Kan du förklara för mig vilket designproblem som finns i hw-raid som gör att du tappar all data?

Jag känner folk som arbetar på massiva datacenters och de har aldrig stött på write hole problemet.

Förklaringen är busenkel: Precis som vilken vettig person som helst så använder de RAID-kontrollers med batteri-backup.

Gå till inlägget

Jag har postat alla nedanstående länkar tidigare.

Här har du lite mer info om t.ex write hole error som hw-raid är känsligt för, som mats42 pratar om
http://blogs.oracle.com/bonwick/entry/raid_z

Här har du några fler design problem i hw-raid:
www.baarf.com

Och sen har jag postat länkar som säger att raid-6 är osäkert, att raid-6 gissar när den försöker korrigera datafel, och kan i värsta fall korrupta ännu mera data.

Ett annat designproblem i hw-raid är att de inte skyddar mot bitröta och silent corruption. De har inte end-to-end checksummor, och det ser jag som ett stort problem. Det finns folk som klagar på ZFS och säger att ZFS tappar data och andra problem, när de bytt till ZFS på samma hårdvara. Men det de inte förstått, är att ZFS detekterar alla problem och rapporterar det. Tidigare hade de alla dessa problem, men fick ingen rapport om det.

Folk har aldrig tidigare kört ett filsystem som har end-to-end checksummor som detekterar alla fel väldigt tidigt, och tror att alla felrapporter orsakas av ZFS, och kanske tidigare skyllt alla problem på buggig mjukvara/OS, när det i själva verket var hårdvaran som krånglat. T.ex. datorer utan ECC RAM står för 20% av alla Windows krascher enligt MS - och då skyller folk på Windows när det i själva verket var non ECC RAM som var problemet. Windows fick felaktigt skulden. På samma sätt får ZFS felaktigt skulden. Men det är ju inte smart att gå tillbaka till sin gamla lösning som aldrig var designat för att detektera eller reparera såna fel. Frånvaron av felrapporter, betyder inte att felen är borta. Bara att man inte får någon rapport om felen.

Jag vet inte riktigt, men det känns som att du och jag har gått igenom denna diskussion tidigare?

Citat:

Tror du att vanliga diskkontrollers är buggfria? Speciellt om du följer "best practice" för ZFS och köper billiga* komponenter?

Jag tror inte vanliga diskkontrollers är buggfria, men jag tror de är buggfriare än ett hw-raid som har massa komplex kod. Och best practice för ZFS är inte att köpa billiga komponenter. Det finns billiga komponenter som ljuger om vad de gjort och inte följer standarder - fusk verk helt enkelt. Det viktiga är att köpa komponter som följer standarder och inte ljuger "ja, nu har jag skrivit ned allt" - när i själva verket inte är nedskrivet. Allt för att få bättre benchmarks, eller lathet, eller billighet

Citat:

RAIDZ skyddar bara mot att du tappar enskilda diskar och inte hela kontrollers.

Jag förstår inte vad du försöker här. Menar du att hw-raid skyddar mot att du tappar hela kontrollers? Om du inte menar att hw-raid skyddar mot trasiga kontrollers, varför nämner du då fel som inte heller hw-raid klarar av? Vi är väl intresserade av skillnaderna mellan ZFS och hw-raid? Inte gemensamma saker? Kan du inte säga nåt i stil med "RAIDZ skyddar mot att du tappar enskilda diskar, och inte hela disk kontrollers, därför anser jag att följande slutsats är befogad:....". Jag förstår inte riktigt vilken slutsats som är meningen att jag ska dra här?

Citat:

* = Jag vill egentligen argumentera emot kostnadsanalysen för ZFS. På min hemma-server så har jag själv haft enorma problem med att hitta billiga diskkontrollers med många portar och som inte är totalgimpade när det kommer till prestanda. Att köpa en vanlig RAID-kontroller och sedan köra JBOD känns inte alltför kostnadseffektivt. Kombinationen Sandy Bridge-E och X79 verkar dock vara riktigt, riktigt intressant.

Ja, om du tycker det är billigare att köpa ett Areca kort eller nåt sånt, istället för en diskkontroller med SATA portar så är det nog bättre att du köper ett hw-raid kort.

Citat:

Heh, lustigt att du nämner programmeringstävlingar som om de har någon som helst relevans för denna diskussion. Det finns dessutom en god chans att kommentaren slår slint.

Det finns nog ingen som argumenterar emot att folk tappar data trots hårdvaru-RAID. Vissa redan nämnt att RAID (i alla dess former) inte kan ersätta goda backuprutiner. Frågan du borde ställa till din vän är om han vet vad som orsakade dataförlusterna. Jag har själv kommit i direkt kontakt med både trasiga minnesmoduler och kontrollerkort som slutar att fungera efter en viss tid.

Jag försöker säga att snubben är grym på IT och vet vad han sysslar med. Han har med största sannolikhet djupare kunskaper än både dig och mig tillsammans. En av de bättre i Sverige.

Citat:

Praktiskt visar det sig att ZFS och mjukvaru-RAID har sämre prestanda för krävande användningsområden [enligt min egen erfarenhet och uppenbarligen även enligt mats42's].
Praktiskt visar det sig också att när ZFS väl failar så failar den oftast katastrofalt.

Ja, Youtube sade ju att de fick högre prestanda med mjukvaruraid när de slutade med hw-raid. Så det kanske är en förhastad slutsats som du drar? Sen finns det ZFS benchmarks som visar att det slår det mesta.

När ZFS väl failar, så har det kanske slutat i katastrof. Men när hw-raid failar, tror du att det går bra? Om jag googlar lite på hw-raid och dataförlust, tror du att jag inte hittar någonting?

Du säger ofta att ZFS orsakar total dataförlust, och därför är det ett argument till att köra hw-raid istället. Men jag säger inte att hw-raid orsakar total dataförlust, vilket händer väldigt ofta. Kanske bör vi diskutera saker som skiljer istället för att diskutera saker som båda råkar ut för? Om du nämner att "ZFS kan tappa data, ha!" - så vet jag inte riktigt vad det tillför för ny synvinkel på diskussionen? Ska jag svara "det gäller också hw-raid, ha!" eller? Eller ska jag skriva "ZFS kan använda allt RAM som disk cache, och ett hw-raid kort har mycket mindre RAM som diskcache, ha!", men på det svarar du bara "hw-raid serverns RAM används också som disk cache, ha!" - jag tycker det är menlöst att jag pratar om saker som även finns på hw-raid?

Citat:

Det sista, om något, är väl ZFS's värsta "designproblem" (nåja - låt oss kalla det för "tradeoff" istället). Recovery-verktyg är så vitt jag vet i princip obefintliga för ZFS p.g.a. filsystemets komplexitet. Har man förresten ens lagt till möjligheten att ångra "zfs destroy" idag?

Det finns recovery för ZFS har jag sagt ju. Om det skiter sig, så kan du göra rollback i tid till senaste fungerande statet. Denna funktion fördes in hyfsat nyligen. Återigen, alla gamla data är kvar intakta och orörda. Alla ändringar sparas på ett nytt stället på disken. Om något skiter sig, så kan du alltid backa i tiden. Men du förlorar upp emot 30 sekunders skrivningar då. Detta har jag nämnt.
http://c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recover...

När du pratar om att ångra zfs destroy, kan man göra det i andra filsystem? Jag tror inte man kan ångra sig än. På UFS kan man väl inte ångra sig, tror jag.

Citat:

Vad tror du är mest komplext och har flest rader kod, och därmed sannolikt flest buggar?

Jag är övertygad om att ZFS är mest komplext, och har mest kod. Men samtidigt, koden är vältestad och det är många som grottar i koden, både från Oracle och FreeBSD och många andra utvecklare. Ett hw-raid har liknande funktionalitet, men det kanske är totalt 5-10 utvecklare som grottar däri. Vem tror du har flest buggar? När ZFS har buggar, så får vi veta det offentligt. När hw-raid har buggar så får ingen veta det.

Citat:

Bara för att man redan har hårdvaran så betyder det inte att den inte redan används. Från pris, prestanda och driftkostnads synvinkel så är det bara dumt att behöva punga ut med ännu mera pengar på maffigare processorer bara för att kunna köra mjukvaru-RAID.

Jag måste uttrycka mig särdeles otydligt, märker jag.

Jag menar inte att man ska byta ut sin cpu mot en maffigare för att köra mjukvaru raid. Jag menar att om du redan har en cpu, varför inte använda den cpu till att även köra mjukvaruraid, istället för att köpa extra hw? Jag vet inte hur många ggr: jag frågat detta och du har kommit med svar som visar att jag inte lyckas formulera mig rätt.

Citat:

Skrivcache Av = För dålig prestanda.
Skrivcache På = Garanterar ej D i ACID vid OS-krash.

Slutsats: ZFS dugger inte till transaktionssystem med prestandakrav.

Ok, så då går du med på att ZFS kan användas till ACID databaser nu?
"Ajdå! Verkar som man i så fall inte kan använda ZFS för ACID-databaser överhuvudtaget (i.e. du tappar D-et)."

För övrigt tror jag det finns företag som kör transaktionssystem på ZFS med höga prestandakrav. Jag vet att det finns flera artiklar om företag som berättar att de kör sina databaser på ZFS servrar nu.

Citat:

Nej, det är inte så journalförande filsystem vanligtvis fungerar.
1) Du behöver inte läsa upp journalen från disk igen eftersom samma information redan finns i minnet.
2) Det är bara metadata som skrivs till journalen.
Databas-applikationer brukar dessutom förallokera uttrymme på disken vilket gör att filsystems-journalen inte involveras överhuvudtaget under normala operationer.
ZFS är annorlunda då ZIL verkligen är en skrivcache.

Ok, det visste jag inte om journalförande filsystem. Menar du att databaser inte använder sig av journalen?
Har du mer info, så kan jag dubbelkolla de saker du säger?

ZIL är en skrivcache, japp. Det låter som att du säger att ZFS inte kan ge höga prestanda, pga ditt och datt. Men jag påstår att det finns benchmarks med höga ZFS prestanda, och det finns företag som kör t.ex transaktionsintensiva databaser på ZFS.

Citat:

Varför börjar du helst plösligt prata om hårdvaru-RAID med SSD:n? Nåja, låt oss lägga till det scenariot också:

Jag pratar inte om hw-raid med SSD. Eftersom du antar att jag ska dra samma slutsatser som du gör, så måste jag hela tiden fråga hur du menar. Och då frågade jag om du menade hw-raid med SSD. Hur menade du, om det inte var det du menade?

Citat:

1) RAID-6 med 18st SSD:n vs RAIDZ2 med 18st SSD:n.
2) RAID-6 med 18st mekaniska diskar vs RAIDZ2 med 18st mekaniska diskar och 1st/2st SSD:n för ZIL.
3) RAID-6 med 18st mekaniska diskar vs RAIDZ2 med 18st mekaniska diskar

Dessa ger oss följande resultat:

1) Hårdvaru-RAID har 16 gånger fler IOPS än ZFS.
2) SSD:n är en single-point-of-failure. SSD:n flaskar skrivningar. Skrivcyklerna gör att du måste byta ut SSD:n en gång per två månader även om du bara skriver med 200 MB/s till arrayen.
3) Hårdvaru-RAID har 16 gånger fler IOPS än ZFS.

Är det tydligt nog för dig?

Nej. Vad försöker du säga? Kan du försöka vara lite tydligare med den slutsats du förväntar dig att jag ska dra? "Jag försöker visa här att följande..."

Nu gissar jag, eftersom du inte är tydlig. Jag gissar att du menar... att hw-raid ger mer IOPS, och att SSD som skrivcache inte är en bra ide, därför att man måste byta den pga man skriver sönder den. Men detta är bara gissningar från min sida, jag vet inte riktigt vad som är din poäng. Det känns som att ganska många av mina inlägg är frågor till dig, om hur du menar. "Vad som är tydligt för dig, behöver inte vara tydligt för mig". Betrakta mig som dum, och var gärna lite övertydlig.

För det första, jag håller med om att hw-raid rent generellt ger mer IOPS än raidz. Det är sant. Men ingen skulle bygga en ZFS lagringslösning som du beskrivit. För det första skulle man haft två raidz2. Och sen skulle man haft en SSD som läs cache också, om nu man vill få upp IOPS. Det finns ju ZFS konstruktioner med SSD som ger 100.000tals IOPS. Den hw-raid du beskriver ovan har 150 IOPS per hårddisk, dvs 16 diskar x 150 IOPS = 2400 IOPS. Så det finns snabba ZFS konstruktioner om IOPS är viktigt.

Angående ZIL, den skriver ned all data som finns i ZIL med jämna mellanrum. ZIL buffrar upp alla skrivningar och tömmer SSD cachen ned till diskarna. För de flesta scenarier duger detta. ZIL ska typiskt vara lika stor som RAM, inte större. ZIL ska ju bara cache upp det som ligger i RAM. Så man har normalt aldrig stora ZIL på flera 100GB.

Sen pratar du bara om hastighet. Men om jag vänder på steken och pratar om bitröta och säkerhet och datakorruption då? Om det är viktigt för företaget att det datat som skrevs ned, också läses korrekt, då är ju hw-raidet inte en lösning att betrakta.

Citat:

Jag citerar: "Då förlorar du senaste ändringarna iofs, som kan sträcka sig ända upp till 30sekunder. Det är ett litet problem dock, tycker jag."

Att ha praktiska problem med att tappa 30 sekunder är inget man tycker. Antingen har man det, eller inte. Låt oss inte kasta sten i glashus.

Detta förstår jag inte alls. Kan du försöka vara lite övertydlig? Jag påstår att det finns benchmarks där ZFS är snabbare än hw-raid, och på det svarar du "jasså, du förlorar senaste 30 sekunderna när du försöker göra recovery och rollback på ZFS? Kasta inte sten i glashus!". På detta svarar jag: Que? Hur menar du? Kan du försöka vara lite övertydlig?

Om ZFS skiter sig, och du måste försöka reparera allt, så backar du tillbaka i tiden och förlorar då upp till de senaste 30 sekunder av skrivningar. Vad har det med snabba ZFS benchmarks och glashus att göra? Seriöst, kan du försöka vara lite övertydlig? Se mig som väldigt korkad, så slipper jag kanske be om förtydliganden hela tiden.

Sist vill jag fråga dig om vad vi är oense egentligen? Det känns som att du säger emot, bara för att?
-ZFS kan tappa data, ha!
-Ja, det kan hw-raid också.
-Jojo, men... ZFS är långsammare, ha!
-jo, men då kan du lägga till lite SSD om du verkligen måste ha snabbhet, förutom att datat ska vara skyddat mot bitröta
-jo iofs, men hw-raid skyddar också mot bitröta
-jaså, visa länkar då
-det finns inga såna länkar, nu pratar vi om nån annan brist i ZFS istället
etc

Vad är din poäng med att säga emot hela tiden, och vad är vi oense om egentligen? Kan du förtydliga det i några punkter? Och var snäll och skriv tydliga slutsatser också. Det värsta exemplet var ju när du presenterade lite C-kod och sade typ "är detta tydligt nog för dig?". Nej, det var inte tydligt för mig. Om du vill visa en bugg så måste du ge ett case där buggen visar sig, du måste säga "om du stoppar in detta som indata så kommer utdata bli så här..., vilket är en bugg eftersom utdatat ska egentligen vara så här..." - då är det tydligt. Man kan inte presentera lite kod och fråga "är detta tydligt nog?". En annan gång presenterade du massor av siffror och skrev nåt i stil med "Se här!" och då undrade jag, "vad är det jag ska se?". Så lite övertydlighet tack. Annars tror man ju att det dunkelt sagda, är det dunkelt tänkta.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag drar mig ur tråden nu eftersom det är alldeles för tidskrävande att diskutera med dig, speciellt då du inte verkar förstå (eller inte är villig att lyssna på) motargument.

Bara en sista kommentar innan jag tackar för mig:

Skrivet av saddam:

Jag försöker säga att snubben är grym på IT och vet vad han sysslar med. Han har med största sannolikhet djupare kunskaper än både dig och mig tillsammans. En av de bättre i Sverige.

Gå till inlägget

Programmeringstävlingar säger i allmänhet inget som personens IT-kunskaper.

Detta kommer från någon som mycket sannolikt skulle placera sig på topp-10 listan över dem mest bäst tävlingsresultat genom tiderna i Sverige, om det nu hade funnits någon sådan lista.

Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Redigera
Citera flera Citera
Permalänk
Rekordmedlem ★
●

Nu är ju reguljära uttryck nått man inte använder så jätteofta i samband med lagringsservrar, men man kan ju alltid bygga en "ultimat" hw raidkontroller som löser allt, det lär finnas en marknad för den om man får den att funka och kan dokumentera det.

Visa signatur

R5 5600G, Asus ROG STRIX X470-F Gaming, WD SN850X 2TB, Seasonic Focus+ Gold 650W, Aerocool Graphite v3, Tittar på en Acer ET430Kbmiippx 43" 4K. Lyssnar på Behringer DCX2496, Truth B3031A, Truth B2092A. Har också oscilloskop, mätmikrofon och colorimeter.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

För att sammanfatta lite:

1. en CPU är inte ledig i en server. Inte heller moderkortet. Därmed finns det ingen magisk gratis kapacitet att utnyttja utan varenda I/O kostar pengar och använder man inte H/W kontrollers så blir det mer I/O i systemet och därmed högre driftskonstnader

2. Jag tror inte att data går förlorat om det enbart ligger i ram. Det är förlorat. Använder man då RamCache i ZFS så är det datat borta. Du får annars förklara hur data finns kvar i ram vid minnesförlust utan batteriskydd

3. Du vill verkligen inte förstå att HW kontrollers hanterar designsvagheterna. Vill du ha mer information får du leta rätt på den på HP och HDS hemsidor. Du hadde tom infomation på dina egna länkar om hur bättre kontrollers försvarar sig. Jag har ärligt talat inte tid eller ork att leta rätt på informationen åt dig utan det får du göra själv. Jag nöjer mig med att konstatera att enligt dina länkar borde jag ha jobbat dygnet runt med att läsa tillbaka backuper från band. Jag har aldrig behövt göra det vilket tyder på att verkligheten har en klart annan uppfattning

4. Om dina bekanta är såpass odugliga att de inte klarar att drifta system utan att kracha dem så borde de kanske anlita någon mer kompetent ja. Jag har som sagt några tusen raidsystem bakom mig och noll dataförslust. Det räcker gott för mig och mina kunder.

5. Har du fortfarande inte begripit skillnaden på läs och skrivprestanda. Tror du att youtube har mer skriv än läs så får du väl tro det. Och återigen så går du efter nått du har hört eller nått du tror medans vi går efter praktiska erfarenheter ur den verkliga världen.

6. Varför har ingen av oss som jobbar aktivt med Raid några problem? Write-hole problem finns inte på en kontroller med batteribackyup hur mycket du än vill tro det. Alternativt får du bevisa att det finns med en batteribackupad kontroller och inte med en svepande generell länk.

7. Att ha journalen på en disk är riktigt dåligt ja. Man vill absolut inte riskera att förlora en journal så att ha den på en disk är mycket dåligt. Dels kommer man att överbelasta den disken och är det en SSD så kommer man att skriva sönder den snabbt . Nu tror jag inte att ZFS funkar så just pga av att det är så korkat. Med en HW kontroller behöver man dessutom inte göra flera I/O utan man skickar ned det till kontrollern och låter den hantera det hela.

8. Kan du förstå att det är mer jobb att först skriva till SSD, sen läsa från SSD, sen skicka skrivorders till ett antal diskar än det är att skicka en skrivorder till en HW Kontroller.

Du har helt klart lite jobbigt att förstå hur I/O hanteringen fungerar men om vi gör en liknelse mellan en dator och ett kontor så innebär CPU baserad hantering i princip att chefen ställer upp en kö människor, säger åt den första att hämta första sidan i boken. När han kommer tillbaka så skickar chefen nästa gubbe och hämta sidan två osv tills chefen har fått tillbaka alla sidor. Sen får chefen sortera dem i ordning om någon nu har rört till det hela, sen kan cefen läsa boken. Med en kontroller har du en underchef. Till honom säger chefen - Hämta alla sidor i den här boken och sortera dem åt mig. Sen får chefen tillbaka en färdig bok att läsa. Gissa vad som spar mest på den dyra Chefens tid (CPU/moderkort).

9. Återigen samma svar. Du kan inte spara allt på nya ställen. Vad gör du när disken blir full? NU börjar du skriva över data eller ska du stoppa systemet?
Du svarade ju inte på hur det funkade med 200 GB overwrite på en disk som är mindre så natingen gör du det nu eller så är det bara att konstatera att du inte vet hur det fungerar heller.

10. Skulle en tillverkare av HW raid controllers ha alvarliga buggar så blir det tämligen synnligt för oss som jobbar i branchen. Börjar det ramla raidset från en tillverkare så lär nog folk dra en slutsats av det, men eftersom det inte inträffar i verkligheten så det visar återigen hur driftsäkra de är.

11. Du svarade aldrig på om du arbetade aktivt med drift eller inte.

12. Du hävdade ju å det bestämdaste tidigare att det bara var windows som var känsligt för dåligt minne men nu hävdar du att alla är känsliga, är alla OS lika känsliga eller vill du nu förklara hur Unix kan läsa minne som inte längre är läsbart?

13. ZFS har fortfarande designproblem (förlusten av prestanda vid skalning), Implementationsporblem (tji writecache om du ska ha datasäkerhet) och driftsproblem i form av buggar.

Sen för att återvända till ursprungsfrågan så kan jag väl iofs besvare den på ett lite annat sätt också.
En av mina kunder la en liten order i veckan. 250 nya servrar. Samtliga kommer att köra Raid5 med writecache.

Senast redigerat
Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●

Men oj vilken lång och meningslös diskussion där så många tycker till.. och här kommer jag med sanningen och ljuset (och ni som inte förstår ironi… skit ner er)

Jag orkade faktiskt inte ens läsa alla kommentarer eller påståenden, detta för att så extrem många blandar block-access med fil-access så mycket att det gör ont i själen.
Dessutom så har många som tycker olika, lika mycket rätt, men inte på samma tillämpning.

ursprungsfrågan

Citat:

Sånt är ju svårt att sia om, men min gissning är att hw-kort kommer försvinna. Om du kan göra allt i mjukvara, så varför använda hw-kort?

Här är det korrekta svaret givetvis Ja! och Nej!

Datorn CPU kommer i allt högre grad att nyttjas i både mjukvaruraid och så kallad "fake-raid" just för att vi inte utnyttjar CPU i våra maskiner. Så varför inte göra det?
HP kommer snart (om de inte redan gjort det) att nyttja serverns CPU för mycket av raid-funktionaliteten på hela deras SmartArray sortiment. Men att blanda in XOR beräkningarna i detta är lika dumt som att påstå att det kommer regna köttbullar i morgon. XOR görs i ASIC och inte av CPU, även på de mest banala HW-raid kort.

Så, det är alltid en avvägning. Du har ju köpt en CPU som skall göra ett jobb. Om du köper tillräckligt mycket CPU så att den även räcker till för att sköta RAID, so be it.. ur ett prestanda perspektiv.

Men RAID-korten gör så mycket mer än så idag, inte minst när vi skall hantera en trasig disk och återbygga spare-disken. Denna trafik och paritetsberäkning vill du inte göra på en server-cpu som samtidigt skall se till att leverera tjänster till verksamheten precis som vanligt.

Men den absolut största anledningen till att HW-raid inte kommer att försvinna har med (som några redan varit inne på) applikationsintegration, senast de vStorage API:er som VMWare släppt för ESX och ESXi. Jag pratar givetvis om VAAI. I korta drag handlar det om att applikationerna (i detta exempel ESX/ESXi) låter hårdvaran göra storageintensiva och storagenära operationer (som exempelvis extended SCSI command xCopy som görs vid storage-vmotion). Detta för att datalagret är betydligt bättre plats att göra det på. Dels för att det går snabbare och för att det är en billigare plats att implementera det på.

Det får mig givetvis in på de tre parametrarna vi har att leka med när vi bygger en IT-infrastruktur.
1. Pris
2. Prestanda
3. Tillgänglighet.
Det tråkiga i kråksången är att du enbart får välja två av dessa… vill du ha hög tillgänglighet och bra prestanda så kommer det kosta. Är prestanda viktig men tillgängligheten inte så viktig så kommer du undan billigare… ja ni förstår säkert vad jag menar.

Och så länge det är billigare att implementera RAID i HW än att göra det i SW så kommer HW finnas kvar. Men, idag så har vi som sagt mycket billig hårdvara i CPU, RAM vilket gör att i små miljöer (som små företag/organisationer och hemma miljöer) så finns det ingen anledning hur ett pris/prestanda perspektiv att investera i HW-raid. En stor anledning till varför det är billigare att implementera en högpresterande och tillgänglig RAID-lösning i HW är hur kösystemet mot disk fungerar och därför är exempelvis en cache på ett RAID-kort ger så ofantligt mycket i prestandavinst att det skulle krävas mångdubbelt mycket HW i servern för att uppnå samma prestanda.

En annan stor anledning till att HW-raid kommer finnas kvar är kluster. Kluster kräver i de allra flesta fall en delad lagringsmiljö, detta är både komplex och svår administrerat att lösa med mjukvara vilket gör att det både blir billigare ur ett OPEX-perspektiv att implementera i hårdvara än motsvarande lösning i mjukvara.

Med det sagt så finns det ytterligare anledningar till HW-raid kommer finnas kvar i en överskådlig framtid (om inte för alltid, tills RAID inte längre håller måttet). Och detta är features/functions. Funktioner som dedup, thin-provisioning, dynamic page tiering, wide striping, etc. dessa kan implementeras transparent från servermiljön, vilket ökar både tillgänglighet och prestanda men samtidigt minskar administrationen jämfört med en implementation i mjukvara.

Så… detta tjaffs med ZFS, btrfs och andra nya filsystem. Jag håller med, de är superduper och måste implementeras förr eller senare. Men de är LÅÅÅÅNGT ifrån en ersättare till HW-raid. Både ZFS och btrfs är filsystem med allt vad det innebär, de lämpar sig alldeles utmärkt för majoriteten av den data vi genererar, och faktum är att file/content växer extremt mycket mer än vad block IO-gör. Men vi kommer väldigt länge till behöva ren IO mot en raw-device där ett filsystem med de features/functions lägger på för mycket overhead och gör det dyrare att implementera än hw-raid. Vi i branchen har länge sagt att vi måste komma med något nytt, något som ersätter RAID. Men på grund av att det saknas en öppen implementation av raid-ersättning så kommer vi få leva med att vi hårdvarutillverkare kommer med egna proparitära lösningar på RAID-problematiken och där är olika typer av mjukvaror ett plåster på såret.

ZFS saknar en distribuerad lock-manager vilket gör det svårt att implementera i en scale-out lösning. Även btrfs saknar detta.
ZFS och btrfs är inte en ersättare för HW-raid, MEN den kan ta över behovet av vissa implementaioner av HW-raid och gör HW-raid mer eller mindre en kostsam redundans.

Slutligen, din hemma miljö och "topp-tweakade" hem-PC är inte en spegel som visar verkligheten

Så, sammanfattningsvis:
1. HW-Raid på små hemma miljöer har aldrig varit intressant ur ett pris/prestanda perspektiv
2. ZFS, btrfs och andra "new generation filsystem" kommer ersätta sw-raid på hemmamiljöer (hw-raid har aldrig varit aktuellt på hemma miljöer), men inte i ett enterprise
3. RAID != Filsystem. Alltså, där vi behöver rå IOPS mot rådevice så kommer inte ZFS, btrfs eller andra smarta filsystem vara aktuellt att implementera eftersom det kommer vara dyrare än HW-raid.
4. Sitter du med HW-raid på din hemmamiljö så är du lurad

Inlägget av mats42 tycker jag är en mycket bra sammanfattning, men jag tror samtidigt att många i tråden har svårt att skilja på hem-PC och Enterprise, därför tror jag att "vi" har diskussionen. Några jämför hem-pc och små miljöer med enterprise och andra glömmer att allt är inte enterprise.

Slut på meddelande… let the trolling begin.

Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det enda jag vill lägga till i den korta sammanfattningen är
5. Ström är pengar. Stora pengar i en datahall och därmed är energieffektivitet mycket viktigt. Att då behöva lasta den varmaste komponenten i systemet mer är inte bra då kylbehovet sticker med kvadraten på effekten.

Sen på den "lättare" sidan. Va har man inte HW raid hema? Det var ju enda sättet att få tillräcklig I/O till min virtualiseringsserver

Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av mats42:

Sen på den "lättare" sidan. Va har man inte HW raid hema? Det var ju enda sättet att få tillräcklig I/O till min virtualiseringsserver

Gå till inlägget

Hehe.. jag drog alla över en kam här. Det jag menar är att fake-raid och/eller mjukvaruraid, till och med "smarta filsystem" är oslagbart ur ett pris/prestanda på de allra flesta hemmamiljöer och lågtpresterande behov där pris är den absolut tyngsta parametern i pris, prestanda & tillgänglighets-formeln.

Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Absolut. Kunde bara inte låta bli (Och nej jag hadde aldrig köpt den controllern för "rätt" pris)

Jag brukar köra pris prestanda och sen kalla det säkerhet istället för i triangeln men i övrigt så håller jag med fullständigt.

Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Avstängd
●

BarreGargamel,
Bra inlägg tycker jag. Men det stora skälet att köra ZFS, är inte prestanda eller nåt annat. Det enda skälet, är att ZFS skyddar mot bitröta. T.ex. postade jag en länk där en dator sparade data på en SAN zfs server. ZFS klagade direkt på att det är något fel i lagringen. Det visade sig vara fel på en Switch som satt mellan datorn och SAN storageZFSservern. ZFS detekterar alla möjliga fel, pga end-to-end checksummor. Hw-raid skulle aldrig märka om en Växel eller Router, var trasig. Men det märker ZFS. Sen om hw-raid är 10% snabbare, så vad spelar det för roll? Datat kan ju bli korrupt.
http://jforonda.blogspot.com/2007/01/faulty-fc-port-meets-zfs...

mats42,
Jag tycker det är lite märkligt att du inte vill inse att bitröta förekommer.

Du påstår massa saker, t.ex att hw-raid skyddar mot bitröta, och när jag ber om länkar - så orkar du inte leta efter dem, utan istället ska jag gå till HP och HDS hemsidor och leta efter argument till de saker du påstår. Du ber mig bevisa dina påståenden, som jag ifrågasätter. Det är en lite märklig argumentationsteknik? Att be opponenten bevisa dina påståenden? Hur skulle det se ut i rätten, "jag som åklagare påstår att Kalle är skattesmitare, och du som hans advokat får bevisa det åt mig"?

Så här är det, jag tror inte det finns några länkar som säger att hw-raid skyddar mot bitröta, av det enkla skälet att hw-raid inte är designade för det. Så när du ber mig bevisa att hw-raid skyddar mot bitröta, så går det inte att bevisa. Min poäng är alltså: Det går inte att bevisa något som är fel. Det är därför du inte kommer att kunna posta såna länkar.

Din argumentation går något i stil med:
Du framhärdar gång på gång att du inte råkat ut för kraschande raids under alla dina år, och därför finns inte bitröta/Silent Corruption/etc. Men hur yttrar sig såna fel såsom t.ex bitröta? Att raidet kraschar och du tappar alla data? Nej. Så är det inte. Om du tror det, så tror du fel. Du kastar ur dig massa saker som inte går att belägga.

Det verkar som att den stora knäckfrågan mellan dig och mig, är om bitröta/Silent corruption/etc existerar eller ej. Sen att ZFS har lägre IOPS etc, det håller jag med om. Men jag säger även att det går att få ut höga prestanda ur ZFS om du konfar det rätt, med t.ex SSD caches. Skit i detta, vi verkar vara överens om att ZFS ger lite lägre prestanda, så låt oss enas om det. Skälet till att ZFS ger lägre IOPS, är pga ZFS konstruktion, ZFS skyddar mot write hole error därför ger den lägre IOPS. hw-raid är snabbare men kan råka ut för write hole error. Men poängen att köra ZFS är ju inte prestanda. ZFS gör massa checksums för att säkerställa att datat är korrekt, och det gör inte hw-raid. Det är ytterligare ett skäl att ZFS suger mer cpu och är långsammare än hw-raid. Om hw-raid också skyddade sina data lika bra som ZFS, så skulle hw-raid vara lika långsamt. Skälet att hw-raid är snabbare än ZFS, är att det inte skyddar sina data.

Hur som helst, det verkar som att du framhärdar att du aldrig råkat ut för bitröta (när jag säger bitröta hädanefter, så menar jag även Silent Corruption och andra fel) och du menar att bitröta aldrig drabbar hw-raid. Som bevis anger du att du aldrig tappat några raid sets.

Det är helt fel, menar jag. Bitröta yttrar sig inte så.

Vi jämför med ECC RAM. Om du inte kör ECC RAM, vad händer då? Datorn kraschar ibland? Eller bara sällan? Eftersom dina datorer inte kraschar hela tiden så råkar du aldrig ut för bitröta i RAM? Nej, det är fel logik. Bitröta flippar bitar lite här och där i RAM, och vissa bitar som flippas råkar vara känsliga och kan orsaka datorkrasch. Stora flertalet flippade bitar kommer bara orsaka felaktiga data, t.ex. "0101" råkar bli t.ex. "0100". Detta händer hela tiden i RAM, det hoppas jag du håller med mig om? Det mesta som lagras i RAM är ju faktiskt användardata, inte känslig systemkod.

A) Håller du med mig om att bitar flippas i RAM, och därför behövs ECC RAM? Du är med på detta? Här finns mer info om bitflippar i RAM.
http://en.wikipedia.org/wiki/ECC_RAM#Errors_and_error_correct...

B) Håller du med mig om att det är bara några få bitflippar i RAM som orsakar en total krasch av datorn? De flesta bitflippar orsakar bara felaktiga användardata?

Då vill jag fråga dig, tror du inte att bitflippar händer på diskar? De händer bara i RAM, men ej på disk? Har du hört talas om bitröta på disk? T.ex. gamla floppydiskar kan inte läsas efter några år. Här finns massa info om bitröta på diskar om du aldrig hört talas om det:
http://en.wikipedia.org/wiki/Bit_rot

C) Går du med på att bitflippar även händer på diskar?

Jag vet inte om du hört talas om CERN, men det är ett stort fysikcentrum med tusentals forskare i fysik, och massor av forskare i datavetenskap, och sysadmins och sånt. Kanske ett av de ställen med mest hjärnkapacitet på jorden. Deras stora partikelacceleratorer skapar PetaByte med data, som måste lagras och sen skannar man igenom datat för att hitta Higgs boson. De lagrar tokmycket data och måste lagra det säkert. Tänk om de missar att hitta Higgs boson pga bitflippar? De oroade sig och gjorde ett test.

CERN gjorde ett test på sina hw-raid. De skrev ett bestämt bitmönster t.ex. "0101010101" över hela raidet nonstop. Efter 3 veckor scannade de igenom sina hw-raid och kollade om det var "01010101010" överallt. Vad tror du de fann? Av 3000 hw-raid system som de undersökte så fann de 152 fall där bitmönstret avvek. Det var inte "0101010101" överallt. Det värsta var att hw-raidet hade inte märkt det. HW-raidet trodde allt var bra och gav inga felrapporter eller varningar. SMART rapporterade inga fel. Allt var bra enligt hårdvaran och OSet.

Senare undersökte CERN varför felen uppkom, och ~ 30% av alla fel berodde på buggar i diskarnas firmware. Detta är ju solklart fall av Silent Corruption. Det finns folk som säger att "nej, detta är inte silent corruption, det var ju bara buggar i firmware" - men si, buggar i firmware klassas som Silent Corruption. ALLA fel som inte hårdvaran märker är Silent Corruption, däribland buggar i firmware, SATA kablar som inte är ordentligt intryckta, etc.

http://www.zdnet.com/blog/storage/data-corruption-is-worse-th...

"When CERN checked 8.7 TB of user data for corruption - 33,700 files - they found 22 corrupted files, or 1 in every 1500 files."

Så om dina raid lagrar 8.7TB, så har de 22 corruptade filer, i snitt.

Och hw-raid är inte designade att detektera såna fel, så hw-raid kan inte hitta, än mindre laga såna fel.

Men si, det kan ZFS. Jag har ju postat en länk där en dator lagrar data på en annan storage server, och ZFS rapporterar omedelbart att det förekommer Silent Corruption. Källan till problemen? Jo, en Switch som sitter mellan datorn och zfs storageservern var trasig! Tror du verkligen att ett hw-raid skulle kunnat detektera detta? Att en switch mellan två datorer var trasig? Det finns folk här på Swec, som rapporterar att ZFS klagade på att några enstaka bitar inte lagrades korrekt, och efter att de tryckt in SATA kablarna ordentligt så slutade ZFS klaga. Tror du hw-raid skulle märkt ej intryckta SATA kablar? Tror du hw-raidet skulle kraschat och man tappat alla sina data? Nej. Bitröta yttrar sig inte så. Istället lagras några enstaka bitar fel. Du som driftar system borde oroa dig för sånt:

http://jforonda.blogspot.com/2006/06/silent-data-corruption.h...

"But what kept me up at night was the thought that there is a possibility that at one point in time, my data has experienced what we call silent corruption. This can happen with hard disks. But it does not stop there. Silent corruption can also happen when you have a hard disk controller failure. I can also imagine that there could be bugs with device drivers. I also know that some disks have firmware and that, too, can be a source of problems. Again, if these errors result in a clear I/O error, then that's the best thing that could ever happen because then, we would know that there is a problem and we could deal with it. But what if it is an undetected error? And what if it goes undetected for a long period of time?

So if my database had a silent corruption, how do I know when it happened? How do I know which of my backups is good? A silent corruption could mean that all my backups are useless because it is possible that the problem is older than my oldest backup"

Sen frågar du gång på gång om jag driftar stora system, och nej det gör jag inte. Eftersom jag inte driftar stora system, menar du då att man inte kan lita på mig? Att alla länkar från t.ex. CERN inte kan stämma? Vad har det med saken vad jag driftar, eller inte driftar? CERN vet väl fortfarande vad de sysslar med? Jag har även länkat till forskare i datavetenskap som forskat på data intgritet och sågar hw-raid pga det är osäkert. Eftersom jag inte driftar stora system, så kan man inte lita på den forskningen?

Om du kör NTFS, ext3, UFS, XFS, etc ovanpå hw-raid så borde du vara orolig. Hw-raid är inte designat för att skydda mot bitröta, inte heller är de filsystemen skyddade vilket forskning visar.

Så det finns företag och organisationer som t.ex. CERN som inte bryr sig om det går 2.6GB/sek eller 3GB/sek. Det viktiga är att inga data förvanskats.

Jag håller med om att ZFS kan vara långsammare än hw-raid, det är ju självklart pga alla jäkla kontroller som hela tiden görs, men det går att få höga prestanda ur ZFS om det är ett måste. Frågan är, vad kör du helst, 3GB/sek med förvanskade data, eller 2.6GB/sek med korrekta data?

Att ZFS inte skalar är ju käpprakt fel. Det finns stora ZFS servrar med massor av disk och många cpuer och som ger grymma prestanda. Btrfs är ett filsystem som inte skalar. Prestandan avtar när man stoppar i typ 50 diskar eller så, visar benchmarks. ZFS fortsätter uppåt linjärt. ZFS är ju för Enterprise servrar med stora muskler. Sun bygger inga lösningar som tar stopp vid 50 diskar. Sun har ju stora Solaris servrar som väger 1000kg och kostar många milj kr. Att anta att Solaris ZFS bara klarar av 10 diskar är ju lite galet. Det finns stora ZFS installationer med t.ex. flera miljoner filer i en enda katalog. Har du hw-raid installationer med en miljon filer i en katalog? Om inte, så kanske dina hw-raid inte skalar uppåt? OpenSolaris hade i början problem med så stora kataloger eftersom att lista alla filer, innebar att man läste in alla filer, sorterade dem, och sen skrev ut dem på skärmen. Och det tog tid. Sen skrevs "ls" kommandot om så det går snabbt att lista miljontals filer, man sorterar inte dem först eller nåt sånt. Att påstå att ZFS inte skalar, är ju ganska fel. 100TB filsystem är ju en baggis för ZFS och vilken hemanvändare som helst kan bygga ihop en sån server utan större problem. En del Linux börjar få problem där nånstans, t.ex. RedHat XFS supportar officiellt bara 16TB eller nåt sånt, enligt officiell RedHat information. Det är ju löjligt lite, vilken hemanvändare som helst har större.

EDIT: lade till "eller nåt sånt" när jag pratar om sortera miljontals filer i zfs kataloger

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av saddam:

Det finns stora ZFS installationer med t.ex. flera miljoner filer i en enda katalog. Har du hw-raid installationer med en miljon filer i en katalog? Om inte, så kanske dina hw-raid inte skalar uppåt? OpenSolaris hade i början problem med så stora kataloger eftersom att lista alla filer, innebar att man läste in alla filer, sorterade dem, och sen skrev ut dem på skärmen. Och det tog tid. Sen skrevs "ls" kommandot om så det går snabbt att lista miljontals filer, man sorterar inte dem först eller nåt sånt.

Gå till inlägget

Förmågan att kunna ha många filer i ett dir och jobba med dessa (slå upp filnamn) effektivt hänger ju inte ett dugg på kontrollerkortet utan i filsystem OCH OS.

Sen finner jag det färdjävligt roligt att i alla dina inlägg är orddensiteten på "CERN","ZFS" & "Bitröta" otroligt höga. Jag tror du ska satsa på att enbart använda dom i framtiden så blir inläggen inte så länga... *retas*

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av saddam:

BarreGargamel,
Bra inlägg tycker jag. Men det stora skälet att köra ZFS, är inte prestanda eller nåt annat. Det enda skälet, är att ZFS skyddar mot bitröta. T.ex. postade jag en länk där en dator sparade data på en SAN zfs server. ZFS klagade direkt på att det är något fel i lagringen. Det visade sig vara fel på en Switch som satt mellan datorn och SAN storageZFSservern. ZFS detekterar alla möjliga fel, pga end-to-end checksummor. Hw-raid skulle aldrig märka om en Växel eller Router, var trasig. Men det märker ZFS. Sen om hw-raid är 10% snabbare, så vad spelar det för roll? Datat kan ju bli korrupt.
http://jforonda.blogspot.com/2007/01/faulty-fc-port-meets-zfs...

Gå till inlägget

Nä naturligtvis skulle ett kontrollerkort som sitter i datorn inte märka ett nätverksfel. Datat går från moderkortet via PCI-X eller PCI-Express bussen till kortet så varför i hela H-E skulle man bry sig om nätet?
Sen om du vill prata nät så har man checksummor på paketen http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksum... och återigen så har man vettiga prylar så hanterar de dem också.

Skrivet av saddam:

mats42,
Jag tycker det är lite märkligt att du inte vill inse att bitröta förekommer.

Du påstår massa saker, t.ex att hw-raid skyddar mot bitröta, och när jag ber om länkar - så orkar du inte leta efter dem, utan istället ska jag gå till HP och HDS hemsidor och leta efter argument till de saker du påstår. Du ber mig bevisa dina påståenden, som jag ifrågasätter. Det är en lite märklig argumentationsteknik? Att be opponenten bevisa dina påståenden? Hur skulle det se ut i rätten, "jag som åklagare påstår att Kalle är skattesmitare, och du som hans advokat får bevisa det åt mig"?

Så här är det, jag tror inte det finns några länkar som säger att hw-raid skyddar mot bitröta, av det enkla skälet att hw-raid inte är designade för det. Så när du ber mig bevisa att hw-raid skyddar mot bitröta, så går det inte att bevisa. Min poäng är alltså: Det går inte att bevisa något som är fel. Det är därför du inte kommer att kunna posta såna länkar.

Din argumentation går något i stil med:
Du framhärdar gång på gång att du inte råkat ut för kraschande raids under alla dina år, och därför finns inte bitröta/Silent Corruption/etc. Men hur yttrar sig såna fel såsom t.ex bitröta? Att raidet kraschar och du tappar alla data? Nej. Så är det inte. Om du tror det, så tror du fel. Du kastar ur dig massa saker som inte går att belägga.

Det verkar som att den stora knäckfrågan mellan dig och mig, är om bitröta/Silent corruption/etc existerar eller ej. Sen att ZFS har lägre IOPS etc, det håller jag med om. Men jag säger även att det går att få ut höga prestanda ur ZFS om du konfar det rätt, med t.ex SSD caches. Skit i detta, vi verkar vara överens om att ZFS ger lite lägre prestanda, så låt oss enas om det. Skälet till att ZFS ger lägre IOPS, är pga ZFS konstruktion, ZFS skyddar mot write hole error därför ger den lägre IOPS. hw-raid är snabbare men kan råka ut för write hole error. Men poängen att köra ZFS är ju inte prestanda. ZFS gör massa checksums för att säkerställa att datat är korrekt, och det gör inte hw-raid. Det är ytterligare ett skäl att ZFS suger mer cpu och är långsammare än hw-raid. Om hw-raid också skyddade sina data lika bra som ZFS, så skulle hw-raid vara lika långsamt. Skälet att hw-raid är snabbare än ZFS, är att det inte skyddar sina data.

Hur som helst, det verkar som att du framhärdar att du aldrig råkat ut för bitröta (när jag säger bitröta hädanefter, så menar jag även Silent Corruption och andra fel) och du menar att bitröta aldrig drabbar hw-raid. Som bevis anger du att du aldrig tappat några raid sets.

Det är helt fel, menar jag. Bitröta yttrar sig inte så.

Vi jämför med ECC RAM. Om du inte kör ECC RAM, vad händer då? Datorn kraschar ibland? Eller bara sällan? Eftersom dina datorer inte kraschar hela tiden så råkar du aldrig ut för bitröta i RAM? Nej, det är fel logik. Bitröta flippar bitar lite här och där i RAM, och vissa bitar som flippas råkar vara känsliga och kan orsaka datorkrasch. Stora flertalet flippade bitar kommer bara orsaka felaktiga data, t.ex. "0101" råkar bli t.ex. "0100". Detta händer hela tiden i RAM, det hoppas jag du håller med mig om? Det mesta som lagras i RAM är ju faktiskt användardata, inte känslig systemkod.

A) Håller du med mig om att bitar flippas i RAM, och därför behövs ECC RAM? Du är med på detta? Här finns mer info om bitflippar i RAM.
http://en.wikipedia.org/wiki/ECC_RAM#Errors_and_error_correct...

B) Håller du med mig om att det är bara några få bitflippar i RAM som orsakar en total krasch av datorn? De flesta bitflippar orsakar bara felaktiga användardata?

Då vill jag fråga dig, tror du inte att bitflippar händer på diskar? De händer bara i RAM, men ej på disk? Har du hört talas om bitröta på disk? T.ex. gamla floppydiskar kan inte läsas efter några år. Här finns massa info om bitröta på diskar om du aldrig hört talas om det:
http://en.wikipedia.org/wiki/Bit_rot

C) Går du med på att bitflippar även händer på diskar?

Gå till inlägget

Jag kan inte ge dig länkar som kräver att du har partner login hos HP eller HDS. Vad som finns publikt vet jag inte och jag tänker inte heller leta utan vill du läsa på så får du göra det själv.

Det är du som har hävdat att Raid är så farligt, har så allvarliga buggar osv och mot det har du fått faktiska drifterfarenheter som visar att det inte är ett praktiskt problem. Du har läst, hört, har kompisar osv, mot det har du fått minst två personer med egna verkliga erfarenheter.

Sen får du som klagar på att andra inte kan lägga fram länkar, lägga fram en som visar problem med HW kontrollers och inte genrellea svepande länkar som inte innehåller tillräckliga fakta. Du som hävdar att write-hole existerar på en batteribackupad HW kontroller kan väl då fixa fram lite länkar som visar att det är ett problem. Det är det inte för en en HW kontroller då den har datat i sitt skyddade minne fram till det att den har fått bekräftelse från diskarna att datat liger där det ska. Hur ska du nu få till hålet? Med en mjukvarubaserad lösning och writecache så får man detta problem och det är ett av skälen till att ingen använder den lösningen.

Frågan om vad man gör om Kontroller eller server pajar. Jo man tar då diskarna och minnesmodulen (med batteriet) och flyttar dessa till en likadan kontroller och startar upp systemet. Tidigt (typ 90 tal) var man tvungen att se till att sätta diskarna på samma plats men det har man sen länge fixat. På den tiden låg raidconfigen bara på kontrollern så den utgick från att disk 1 alltid satt på samma plats och kollade inte så man fick vara noga då. Dålig design och det fixades rätt kvickt också.

Tror jag att en HW kontroller upptäcker dåliga kablar? Jag tror inte den här gången heller, Jag vet att den gör det genom att jag har fått sådanna larm och åtgärdat dem. Återigen dataförlust=0.

Skrivet av saddam:

Jag vet inte om du hört talas om CERN, men det är ett stort fysikcentrum med tusentals forskare i fysik, och massor av forskare i datavetenskap, och sysadmins och sånt. Kanske ett av de ställen med mest hjärnkapacitet på jorden. Deras stora partikelacceleratorer skapar PetaByte med data, som måste lagras och sen skannar man igenom datat för att hitta Higgs boson. De lagrar tokmycket data och måste lagra det säkert. Tänk om de missar att hitta Higgs boson pga bitflippar? De oroade sig och gjorde ett test.

CERN gjorde ett test på sina hw-raid. De skrev ett bestämt bitmönster t.ex. "0101010101" över hela raidet nonstop. Efter 3 veckor scannade de igenom sina hw-raid och kollade om det var "01010101010" överallt. Vad tror du de fann? Av 3000 hw-raid system som de undersökte så fann de 152 fall där bitmönstret avvek. Det var inte "0101010101" överallt. Det värsta var att hw-raidet hade inte märkt det. HW-raidet trodde allt var bra och gav inga felrapporter eller varningar. SMART rapporterade inga fel. Allt var bra enligt hårdvaran och OSet.

Senare undersökte CERN varför felen uppkom, och ~ 30% av alla fel berodde på buggar i diskarnas firmware. Detta är ju solklart fall av Silent Corruption. Det finns folk som säger att "nej, detta är inte silent corruption, det var ju bara buggar i firmware" - men si, buggar i firmware klassas som Silent Corruption. ALLA fel som inte hårdvaran märker är Silent Corruption, däribland buggar i firmware, SATA kablar som inte är ordentligt intryckta, etc.

http://www.zdnet.com/blog/storage/data-corruption-is-worse-th...

"When CERN checked 8.7 TB of user data for corruption - 33,700 files - they found 22 corrupted files, or 1 in every 1500 files."

Så om dina raid lagrar 8.7TB, så har de 22 corruptade filer, i snitt.

Och hw-raid är inte designade att detektera såna fel, så hw-raid kan inte hitta, än mindre laga såna fel.

Men si, det kan ZFS. Jag har ju postat en länk där en dator lagrar data på en annan storage server, och ZFS rapporterar omedelbart att det förekommer Silent Corruption. Källan till problemen? Jo, en Switch som sitter mellan datorn och zfs storageservern var trasig! Tror du verkligen att ett hw-raid skulle kunnat detektera detta? Att en switch mellan två datorer var trasig? Det finns folk här på Swec, som rapporterar att ZFS klagade på att några enstaka bitar inte lagrades korrekt, och efter att de tryckt in SATA kablarna ordentligt så slutade ZFS klaga. Tror du hw-raid skulle märkt ej intryckta SATA kablar? Tror du hw-raidet skulle kraschat och man tappat alla sina data? Nej. Bitröta yttrar sig inte så. Istället lagras några enstaka bitar fel. Du som driftar system borde oroa dig för sånt:

http://jforonda.blogspot.com/2006/06/silent-data-corruption.h...

"But what kept me up at night was the thought that there is a possibility that at one point in time, my data has experienced what we call silent corruption. This can happen with hard disks. But it does not stop there. Silent corruption can also happen when you have a hard disk controller failure. I can also imagine that there could be bugs with device drivers. I also know that some disks have firmware and that, too, can be a source of problems. Again, if these errors result in a clear I/O error, then that's the best thing that could ever happen because then, we would know that there is a problem and we could deal with it. But what if it is an undetected error? And what if it goes undetected for a long period of time?

So if my database had a silent corruption, how do I know when it happened? How do I know which of my backups is good? A silent corruption could mean that all my backups are useless because it is possible that the problem is older than my oldest backup"

Gå till inlägget

Jo Cern är rätt stora, Jobbade på ett företag som var leverantör åt dem tidigare så jag har gjort "lite" mer än bara hört talas om dem (tystnadsplikt på exakt vad vi gjorde)

Skrivet av saddam:

Sen frågar du gång på gång om jag driftar stora system, och nej det gör jag inte. Eftersom jag inte driftar stora system, menar du då att man inte kan lita på mig? Att alla länkar från t.ex. CERN inte kan stämma? Vad har det med saken vad jag driftar, eller inte driftar? CERN vet väl fortfarande vad de sysslar med? Jag har även länkat till forskare i datavetenskap som forskat på data intgritet och sågar hw-raid pga det är osäkert. Eftersom jag inte driftar stora system, så kan man inte lita på den forskningen?

Om du kör NTFS, ext3, UFS, XFS, etc ovanpå hw-raid så borde du vara orolig. Hw-raid är inte designat för att skydda mot bitröta, inte heller är de filsystemen skyddade vilket forskning visar.

Så det finns företag och organisationer som t.ex. CERN som inte bryr sig om det går 2.6GB/sek eller 3GB/sek. Det viktiga är att inga data förvanskats.

Jag håller med om att ZFS kan vara långsammare än hw-raid, det är ju självklart pga alla jäkla kontroller som hela tiden görs, men det går att få höga prestanda ur ZFS om det är ett måste. Frågan är, vad kör du helst, 3GB/sek med förvanskade data, eller 2.6GB/sek med korrekta data?

Gå till inlägget

Anledningen till att jag frågade om du jobbar med drift var att försöka fastställa hur mycket du vet om hur man driftar och kör system. Nu kan jag utgå från att du inte vet det minsta om det. Iom det är det ingen ide att gå in i specifika delar utan jag lägger mig därmed på generell nivå istället.

En bra driftmiljö idag är väldigt strukturerad och ordentligt loggad för att man ska ha grepp på alla förändringar och kostnader. En del av detta är att det ska finnas beställningar/felmälningar/jobbid på alla åtgärder som utförs som tex återläsning av fil/katalog/databas. Därmed har vi som jobbar med det rätt bra koll på hur mycket problem vi har och var de sitter.

Vorde då datakoruption ett reellt i den mängd du vill ha det till så borde vi ha ganska många filer som inte går att öppna eller innehåller skadat data(Tex källkod som iten längre går att kompilera). Det har vi inte utan det rör sig om några enstaka filer per månad och när vi tittar på varför så beror det i princip alltid på att användaren har haft filen öppen och tryckt på strömknappen. Dvs döp om tempfilen och problemet löst.

Om vi utgår från att problemet är mindre och det bara är någon enstaka bit och inte destruktivt så är det ju ändå rimligt att vi skulle få problemet i de applikationer som har checksummor på sina filer. SCCM är ju ett sådant system som sätter checksummor på sina paket. Med några hundra SCCM Servrar och ett flöde av paket på dem hela tiden dvs skrivning av nytt data till diskarna så borde vi ju få en hel del checksummefel och därmed restore requests, det får vi inte. SCCM är då ett system för bland annat distribuera mjukvara till datorer.

Vi har även appar med checksumor på AIX, Solaris och Linux plattformarna. Ser vi då en massa trasiga checksummor på dem? Nä, de har inga problem med oförklarigt trasiga checksummor heller.

Därmed så visar verkliga förstahandserfarenheter återigen att problemet är i princip icke existerande så nej, det är inget jag ororar mig för.

Skrivet av saddam:

Att ZFS inte skalar är ju käpprakt fel. Det finns stora ZFS servrar med massor av disk och många cpuer och som ger grymma prestanda. Btrfs är ett filsystem som inte skalar. Prestandan avtar när man stoppar i typ 50 diskar eller så, visar benchmarks. ZFS fortsätter uppåt linjärt. ZFS är ju för Enterprise servrar med stora muskler. Sun bygger inga lösningar som tar stopp vid 50 diskar. Sun har ju stora Solaris servrar som väger 1000kg och kostar många milj kr. Att anta att Solaris ZFS bara klarar av 10 diskar är ju lite galet. Det finns stora ZFS installationer med t.ex. flera miljoner filer i en enda katalog. Har du hw-raid installationer med en miljon filer i en katalog? Om inte, så kanske dina hw-raid inte skalar uppåt? OpenSolaris hade i början problem med så stora kataloger eftersom att lista alla filer, innebar att man läste in alla filer, sorterade dem, och sen skrev ut dem på skärmen. Och det tog tid. Sen skrevs "ls" kommandot om så det går snabbt att lista miljontals filer, man sorterar inte dem först eller nåt sånt. Att påstå att ZFS inte skalar, är ju ganska fel. 100TB filsystem är ju en baggis för ZFS och vilken hemanvändare som helst kan bygga ihop en sån server utan större problem. En del Linux börjar få problem där nånstans, t.ex. RedHat XFS supportar officiellt bara 16TB eller nåt sånt, enligt officiell RedHat information. Det är ju löjligt lite, vilken hemanvändare som helst har större.

EDIT: lade till "eller nåt sånt" när jag pratar om sortera miljontals filer i zfs kataloger

Gå till inlägget

Nu får du allt lov att skilja på vad ett filsystem är och vad som är hårdvara

Att sun har stora servrar är orelevant, det har även HP och IBM tex. En HW kontroller vet inte vad en fil eller katalog är för något så det bryr den sig inte om överhuvudtaget. Den bryr sig om bits och bytes, därmed kan du ha precis hur många miljarder filer du vill så länge filsystemet klarar det.

Det var ju du själv som hävdade att CPU fick mer last ju mer diskar man stoppade dit. Tyvärr så är det sannolikt då någonting måste hålla rätt på diskarna och alla jobb som går till dem och utan en dedikerad kontroller så måste det bli CPU som tar jobbet. Stämmer detta så förbrukar mer av dessa resurser ju fler diskar du stoppar vilket är ett skalningsproblem. Det gör det inte omöjligt att skala ut men måste du köpa en större/dyrare server så ska du ju väga kostnaden för det plus vad den kostar mer i stöm och supportavtal osv mot en annan lösning som tex en HW kontroller. Därmed faller återigen argumentet om att HW kontrollers är så hemskt dyra.

Hur du än vill det så får du inga bra writeprestanda utan writecache.
Att mellanlagra data på en SSD ger inte heller det någon writecache. Att först skriva till en disk för att sen läsa tillbaka det för att slutligen göra en lika långsam skrivning som det hadde varit att göra den från början ger inga prestandavinster i ett system med belastning. Sen har du fortfarande problemet med att den SSD:n kommer att brännas ut rätt fort.

Sen hur mycket man tjänar på writecache är ju naturligtvis beroende på lasten men det handlar inte om 10% i prestandaskillnad mellan writecache on eller off, 10 gånger om är närmare sanningen på en relativt liten server http://laez.nl/vmware-bad-performance-on-hp-proliant-dl380-g6...

Gargamels lilla fråga om Raw-devices/Partitioner/slices är ju också något du måste förklara hur du ska lösa.

Senast redigerat
Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av saddam:

BarreGargamel,
Bra inlägg tycker jag. Men det stora skälet att köra ZFS, är inte prestanda eller nåt annat. Det enda skälet, är att ZFS skyddar mot bitröta. T.ex. postade jag en länk där en dator sparade data på en SAN zfs server. ZFS klagade direkt på att det är något fel i lagringen. Det visade sig vara fel på en Switch som satt mellan datorn och SAN storageZFSservern. ZFS detekterar alla möjliga fel, pga end-to-end checksummor. Hw-raid skulle aldrig märka om en Växel eller Router, var trasig. Men det märker ZFS. Sen om hw-raid är 10% snabbare, så vad spelar det för roll? Datat kan ju bli korrupt.
http://jforonda.blogspot.com/2007/01/faulty-fc-port-meets-zfs...

Gå till inlägget

Jo. ZFS (och andra filsystem) klarar av att upptäcka bit-error end-2-end, men det hjälper inte om det inte presterar eller har den tillgänglighet som krävs av applikationen/tjänsten som skall levereras ut till verksamheten.

Men samtliga av våra firmwares och array-kontrollrar nyttjar möjligheten att formatera SCSI (FC/SAS) disk i 520 bytes block, de extra 8 byte använder vi som just checksum för att garantera att det som en gång skrevs ner till disk är också det som vi läser. Om det skulle blitt något fel vid skrivning till magnetskivan så upptäcker vi detta och kan du nyttja paritet i RAID för att återställa data. Där med eliminera viproblematiken med "bit-error on rest", vilket är den absolut vanligaste formen av bit-error, alltså att den sker på magnetskivan när data ligger på plats, samt från array.kontroller ner till disk.
Jag är fullt medveten om att tillverkare blåser upp FUD om att bit-error är lika vanliga i transporten ner till disk, men det visar inte de studier som gjorts.

Oh... btw.... att använda ett filsystem för att övervaka sitt SAN är enligt mig absurt. Det som skall användas är givetvis en övervakningsprogramvara som är ämnat för detta (finns ett otal att välja på från både SAN-leverantörerna samt tredjepart, best of breads enligt mig är VI (Virtual Instuments: http://www.virtualinstruments.com/)

Personligen gjorde jag vågen när SUN släppte sin OpenStorage och "Unified storage"-strategi, en "hårdvara" med alla features and functions som ZFS skulle leverera men med möjlighet att även dela ut "high performance" block-access. Så lycklig att jag faktisk var med och levererade en multi terrabyte-lösning (400TB+) och som växte otroligt snabbt. Men med facit i hand så ångrar jag detta bittert då den inte skalade så mycket och flexibelt som utlovades, men framförallt för att den inte levererade den tillgängligheten som förväntades.

Men åter igen. På frågan om HW-Raid kommer försvinna så är svaret åter igen ett rungande NEJ! Inte på överskådlig framtid.

En helt annan fråga som konstigt nog debateras i denna tråd: Kommer mjukvaruraid och NextGen filsystem minska behovet av HW-raid. Ja, är svaret på den frågan.

ZFS är inte, och kommer aldrig bli, en totallösning som är bra eller konstandseffektivt att implementera på alla behov. Så enkelt är det.
Kommer framtida filsystem att vara det? kanske, men jag tror inte det eftersom även filsystem är en flaskhals och begränsning i den "tsunamivåg" av ostrukturerad data vi genererar. Lösningen för imorgon är enligt mig och många experter, inte ett filsystem. Det handlar om virtualisera innehåll och information och skapa intelligenta, autonoma och självadministerande "content depos" för vår ostrukturerade data, semi-strukturerade data samt delar av den strukturerade data vi idag nyttjar filsystem och block-device för.

Edit, ändrade "skrivning ner till filsystem" när det skulle vara "ner till disk"

Senast redigerat
Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av saddam:

Du påstår massa saker, t.ex att hw-raid skyddar mot bitröta, och när jag ber om länkar - så orkar du inte leta efter dem, utan istället ska jag gå till HP och HDS hemsidor och leta efter argument till de saker du påstår

Gå till inlägget

Jag jobbar på HDS, jag intygar att det du kallar bitröta existerar. Jag kan också garantera dig att våra arrayer och firmware (som jag sa tidigare) har skydd för detta. Jag kan också understryka att faran för bitröta är kraftigt överdrivna.

Du jämför gång på gång ett filsystem med block-access vilket gör att jämförelsen haltar otroligt mycket och gör diskussionen svår.

Skrivet av saddam:

Så här är det, jag tror inte det finns några länkar som säger att hw-raid skyddar mot bitröta, av det enkla skälet att hw-raid inte är designade för det. Så när du ber mig bevisa att hw-raid skyddar mot bitröta, så går det inte att bevisa. Min poäng är alltså: Det går inte att bevisa något som är fel. Det är därför du inte kommer att kunna posta såna länkar.

Gå till inlägget

Jag skall leta upp en länk om vi har någon på vår externa web, om inte så skall jag lägga upp interna dokument som beskriver hur vi skyddar mot "bitröta" (om jag får tillåtelse att publicera dokumentet d.v.s.)

Skrivet av saddam:

Så om dina raid lagrar 8.7TB, så har de 22 corruptade filer, i snitt.

Och hw-raid är inte designade att detektera såna fel, så hw-raid kan inte hitta, än mindre laga såna fel.

Gå till inlägget

Det är fel, det finns hårdvara som hjälper till att skydda mot detta, som jag beskrev tidigare genom att formatera SCSI/SAS i 520 bytes block och använda de 8 byte som blir över för checksum, just för att bitflipp kan ske, och om det gör det så är det oftast på ljust magnetplattan.

Skrivet av saddam:

SATA kablarna ordentligt så slutade ZFS klaga. Tror du hw-raid skulle märkt ej intryckta SATA kablar? Tror du hw-raidet skulle kraschat och man tappat alla sina data? Nej. Bitröta yttrar sig inte så. Istället lagras några enstaka bitar fel. Du som driftar system borde oroa dig för sånt:

Gå till inlägget

I ett högpresterande och högtillgängligt system så använder vi givetvis inte kablar, det är befängt.

Skrivet av saddam:

Om du kör NTFS, ext3, UFS, XFS, etc ovanpå hw-raid så borde du vara orolig. Hw-raid är inte designat för att skydda mot bitröta, inte heller är de filsystemen skyddade vilket forskning visar.

Gå till inlägget

Nu drar du alla tillverkare över en kam. Att säga att hw-raid inte har skydd för detta är som att påstå att inga hundar är över 25cm i mankhöjd bara för att du jämför det med en shitsu.

Skrivet av saddam:

Att ZFS inte skalar är ju käpprakt fel. Det finns stora ZFS servrar med massor av disk och många cpuer och som ger grymma prestanda.

Gå till inlägget

Det är inte käpprätt fel, du kan inte skala ut i en ZFS miljö eftersom du inte har någon lock-manager, filsystemet kan bara hanteras på en nod i klustret. M.a.o. så är inte access mot varje givet "block"/fil en aktiv/passive access. Hela arkitekturen bygger på aktive/passive. Ja visst, du kan skapa fler filsystem och lastdela dessa över alla noder, men till varje givet filsystem så är det active/passive.

Skrivet av saddam:

Har du hw-raid installationer med en miljon filer i en katalog? Om inte, så kanske dina hw-raid inte skalar uppåt? OpenSolaris hade i början problem med så stora kataloger eftersom att lista alla filer, innebar att man läste in alla filer, sorterade dem, och sen skrev ut dem på skärmen. Och det tog tid. Sen skrevs "ls" kommandot om så det går snabbt att lista miljontals filer, man sorterar inte dem först eller nåt sånt. Att påstå att ZFS inte skalar, är ju ganska fel. 100TB filsystem är ju en baggis för ZFS och vilken hemanvändare som helst kan bygga ihop en sån server utan större problem. En del Linux börjar få problem där nånstans, t.ex. RedHat XFS supportar officiellt bara 16TB eller nåt sånt, enligt officiell RedHat information. Det är ju löjligt lite, vilken hemanvändare som helst har större.

Gå till inlägget

Nu blandar du filsystem och blockaccess igen. Du kan inte göra den jämförelsen med hur många filer vi kan spara... faktum är att jag kan spara lika många filer i min array som du kan spara filer i ZFS. Det är nämligen fullt möjligt att formatera ZFS på våra arrayer (vilket många också gjort). Block-access är block-access och helt oberoende av ovanliggande filsystem och katalogstruktur.

Har du lust att jämföra prestanda/skalbarhet/tillgänglighet/features/functions på filsystem så lyfter jag fram vår HNAS (High Performance NAS) som är en BlueArc arkitetur. Kan du tänka dig, vi har där valt att implementera filsystem i ASIC, d.v.s. inget OS. Varför tror du? Jo, vill du ha prestanda och tillgänglighet så måste de ske på HW.

Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem
●

Sorry, hittade inte några publika dokument som beskriver 520 bytes formateringen,
men Hu Yoshida (vår Vice President and Chief Technology Officer) nämnder detta i hans blog

Så har du det ialla fall från en mer källa än stackars mig

http://blogs.hds.com/hu/2011/07/say-farewell-to-fc-and-sata-d...

Jag skulle bli förvånad om vi är de enda som gör detta....

Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag med. Man kan nog till med säga att jag skulle bli mycket förvånad om det vorde så att det enbart var HDS som hadde skyddat sig men så var det ju det här med offentlig information igen.

PS att formaterar många satadiskar samtidigt i ett 9585 skåp är obra för prestandan ds

Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●

Så, jag har nu sökt lite bland "kollegor" i branchen och kan konstatera att vi är långt ifrån ensamma om att nyttja 520 bytes formatering. Men det är inte därför jag postar. Jag upptäckte till min stora glädje att vi kan kompliera linuxkärnan med CONFIG_BLK_DEV_INTEGRITY aktiverat för att kunna "native" i vår linuxkernel nyttja 520 bytes formatering på SCSI devices (som jag förstått det) och kan alltså skydda oss från det du kallar för bitröta på SAMTLIGA filsystem som linux supportar, XFS, ext3, ext4 och till och med gamla filsystem som fat32.. och det utan HW-raid alltså...

Så, idag har jag lärt mig något nytt

Skrivet av mats42:

PS att formaterar många satadiskar samtidigt i ett 9585 skåp är obra för prestandan ds

Gå till inlägget

Heheh.. det är ingen bra ide.

Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

En liten nackdel med mjukvaru-raid jag nyligen fick erfara är hur farligt det är tillsammans med överlastade servrar.
En av mina webservers som kör en RAID6 i mjukvaran råkade ut för en attack från en person som använde apache-killer för några veckor sen. Attacken kom mitt i natten så jag märkte inte av det förens på morgonen då apache hade ätit upp alla resuser på servern under 6h, servern låg på ca 50 i load och filsystemet var monterat som ro. Eftersom servern inte hade någon CPU alls tillgänglig längre och inte heller minne så kunde inte mjukvaruraiden jobba som den skulle vilket resulterade i ett korrupt filsystem. Lyckades få liv i GRUB men den kunde inte längre läsa in kärnan. Löste sig ändå då jag hade offsite backup men var ganska irriterande och kan vara värt att tänka på.

Visa signatur

Cisco-certifierad nätverksspecialist
Bygger globalt spelservernätverk på dathost.net

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jo en huvud CPU kan ju liksom få lite annat för sig eller löpa amok. tex. Dåliga drivers/virus/buggar Det är ytterligare ett argument för att få ned det hela i kisel

Senast redigerat
Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●

Pris, prestanda och tillgänglighet!

Åter igen. Jag är möjligtvis tjatig och gnällig

Inget filsystem är svaret på alla behov. Precis lika lite som mjukvaru raid är svaret på alla behov. Inte heller hårdvaruraid är svaret på alla behov.

Den stora faran är att bygga en lagringsstrategi som baserar sig på en teknik (som vi i branschen har en förkärlek att proklamera). Faran är om tekniken plötsligt inte möter upp mot verksamhetens behov, och då är man helt plötsligt tvungen att byta strategi, och är det något som är dyrt så är det att byta strategi.

Byta teknik kan vi göra var och varannan dag, det skall inte behöva förändra våran strategi.

Så... mitt tipps till tråden är att bygga en largingsstrategi som inte baserar sig på en teknik (oavsett om den tekniken kommer från SUN/Oracle, HDS, HP, IBM eller NetApp). Bygg istället en strategi som kan acceptera tekniker från vilken tillverkare som helst. När detta är på plats så har NI verkligen utrymme att priskontrollera de olika teknikerna mot varandra och oavsett vilken teknik eller tillverkare ni väljer så har ni möjlighet att implementera den tekniken i ER strategi.

Sen är det möjligt att strategin och arkitekturen innehar både Smart Filesystem och mjukvaruraid i kombination med hårdvaruraid eller vilken jävla teknik som är hype i morgon.

Så åter igen, nej... .mjukvaruraid eller ZFS kommer inte att döda hårdvaruraid därför att de inte löser alla problem eller tillgodoser alla behov. Precis lika lite som hårdvaruraid kommer att ta dör på filsystem?!?!??! jo.. vänd på frågan så får ni se hur jävla dum den är... Har hårdvaruraid varit ett hot mot filsystem? nej.. precis.. har de någonsin varit antingen eller? nej.. och de kommer inte vara det så länge applikaitonslagret inte klarar av ett öppet API för att lagra content

just my 2 cents

edit: ändrade URL till rätt URL

Visa signatur

________________________________________________________________
twitter @ BarreGargamel
blogg @ Gargamel.NU

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av mats42:

Jo en huvud CPU kan ju liksom få lite annat för sig eller löpa amok. tex. Dåliga drivers/virus/buggar Det är ytterligare ett argument för att få ned det hela i kisel

Gå till inlägget

Fast det där går ju att lösa med mjukvara lika bra, iaf den del som kisel kan lösa.

Visa signatur

Plan9 fan. In glenda we trust.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av dagle:

Fast det där går ju att lösa med mjukvara lika bra, iaf den del som kisel kan lösa.

Gå till inlägget

Jag har lite svårt att se hur man ska kunna göra det. En X86 CPU kan ju inte virtualisera tex I/O lagret eller garantera X antal % CPU till I/O processen utan all schedulering sker ju från mjukvara och en bugg kan ju påverka schedulern. Samma sak gäller ju vad ett virus kan ställa till med.

Ligger det i HW så är det ju skyddat mot en del av dessa problem (en taskig driver gör ju ont oavsett).

Sen är det ju alltid som så att ju mer kod man har snurrande, ju mer risk har man för krash. HW kontrollern är ju specialiserad och kan därmed ha en simplare kodstack vilket gör den lättare att avlusa

Kunde man skriva 100% bugfri kod så skulle ju problemet inte existera men dit har vi nog en bit kvar

Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av mats42:

Jag har lite svårt att se hur man ska kunna göra det. En X86 CPU kan ju inte virtualisera tex I/O lagret eller garantera X antal % CPU till I/O processen utan all schedulering sker ju från mjukvara och en bugg kan ju påverka schedulern. Samma sak gäller ju vad ett virus kan ställa till med.

Ligger det i HW så är det ju skyddat mot en del av dessa problem (en taskig driver gör ju ont oavsett).

Sen är det ju alltid som så att ju mer kod man har snurrande, ju mer risk har man för krash. HW kontrollern är ju specialiserad och kan därmed ha en simplare kodstack vilket gör den lättare att avlusa

Kunde man skriva 100% bugfri kod så skulle ju problemet inte existera men dit har vi nog en bit kvar

Gå till inlägget

Tycker du pratar rätt mycket i nattmössan. Ser inte vad virtaulisera skulle ha med saken att göra. Vad har schedulering med saken att göra? Du sitter i en låda (som många andra i unixvärlden) som du inte kan ta dig ur, problemet går att lösa om du bara ställer dig upp.

Att hårdvara generellt skulle vara skonat från buggar... XD. Drivrutinbuggar är ofta buggar i hårdvara som är billigare att lösa i just mjukvara, frågan är i det fallet vad som är buggigt.

Visa signatur

Plan9 fan. In glenda we trust.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av dagle:

Tycker du pratar rätt mycket i nattmössan. Ser inte vad virtaulisera skulle ha med saken att göra. Vad har schedulering med saken att göra? Du sitter i en låda (som många andra i unixvärlden) som du inte kan ta dig ur, problemet går att lösa om du bara ställer dig upp.

Att hårdvara generellt skulle vara skonat från buggar... XD. Drivrutinbuggar är ofta buggar i hårdvara som är billigare att lösa i just mjukvara, frågan är i det fallet vad som är buggigt.

Gå till inlägget

Byt virtualisera mot partitionera om du vill men vad det handlar om är fortfarande att du behöver kunna garantera systemresurser till en process/operation oavsett vad som händer med resten .

Sheduler funktionen är vad som som tilldelar CPU resurser till de olika trådarna som tex I/O drivern eller den app du vill köra. Dvs lyckas du få till något som påverkar eller stör den så får du rätt allvarliga effekter.

Att man ibland gör workarounds i drivers för att undvika HW problem är rätt men en driver är fortfarande 100% mjukvara och en bugg i den mjukvaran är fortfarande lika illa.

Om du anser att det är så enkelt att lösa så kan du väl redogöra för hur man skulle göra det?
Jag kan tex inte se någon metod för attt garantera att en process som går i ring 0 inte ska kunna ställa till det för annan mjukvara, dvs utan hårdvarustöd för partitionering och det har vi inte på tex X86

Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av mats42:

Byt virtualisera mot partitionera om du vill men vad det handlar om är fortfarande att du behöver kunna garantera systemresurser till en process/operation oavsett vad som händer med resten .

Sheduler funktionen är vad som som tilldelar CPU resurser till de olika trådarna som tex I/O drivern eller den app du vill köra. Dvs lyckas du få till något som påverkar eller stör den så får du rätt allvarliga effekter.

Att man ibland gör workarounds i drivers för att undvika HW problem är rätt men en driver är fortfarande 100% mjukvara och en bugg i den mjukvaran är fortfarande lika illa.

Om du anser att det är så enkelt att lösa så kan du väl redogöra för hur man skulle göra det?
Jag kan tex inte se någon metod för attt garantera att en process som går i ring 0 inte ska kunna ställa till det för annan mjukvara, dvs utan hårdvarustöd för partitionering och det har vi inte på tex X86

Gå till inlägget

Vet vad en Scheduler är. Men varför använda den över huvudet taget när den ställer till problem? Varför inte bara ta en core och allokera den till en process och skita i schedulern för den processesen? Det är inte jättesvårt att skriva en kernel som kan göra det, tbh.

Sedan är kan man säga att dessa speciella processer kan göra (även i ring 0) så att man kan tvinga kerneln preemption på IO resurser på andra processer, detta funkar helt ok för att användaren inte kan öka loaden på coren och den går alltid före vad gäller IO.

Dock så ser infrastrukturen ut så att det är sjukt mycket lättare att lösa detta med hårdvara (för att inte säga billigare) etc och skulle nog inte rekommendera någon att göra det i mjukvara om de inte gör det forskning eller for the lulz, men omöjligt är det inte.

Visa signatur

Plan9 fan. In glenda we trust.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag var av uppfattningen att du inte kunde få skyddet att hålla bra nog på X86 men det är fullt möjligt att det är görbart idag. Jag har ärligt talat inte rotat så djupt inne i CPU på ett tag.

Jag tackar för din förklaring

Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av BarreGargamel:

Men samtliga av våra firmwares och array-kontrollrar nyttjar möjligheten att formatera SCSI (FC/SAS) disk i 520 bytes block, de extra 8 byte använder vi som just checksum för att garantera att det som en gång skrevs ner till disk är också det som vi läser. Om det skulle blitt något fel vid skrivning till magnetskivan så upptäcker vi detta och kan du nyttja paritet i RAID för att återställa data

Här har vi Fibre Channel diskar med såna 520 bytes block du pratar om.
http://www.seagate.com/staticfiles/support/disc/manuals/enter...
Fibre Channel Cheetah 10K.7 FC diskar har 520 byte stora sektorer och rapporterar felfrekvens i kapitel 5.0, där pratas om felfrekvenser för "Recovered Data", "Unrecovered Data" och även "Miscorrected data" - dvs data som reparerades men blev helt fel.

http://www.seagate.com/staticfiles/support/disc/manuals/enter...
Kapitel 5.1.2 säger att denna 520 byte formaterade SAS enterprise disk, råkar ut för fel som inte går att reparera.

Seagate Barracuda ES.2 SAS diskar med 520 Byte stora sectorer inkl checksummor, rapporterar samma felfrekvens, dvs 1 sector blir fel per 10^15.

Så vi ser här några exempel på SAS Enterprise diskar och Fibre Channel Diskar som alla har problem med fel som de inte kan reparera, eller reparerar helt fel. Det som INTE står i Spec sheeten dock, är alla fel som inte disken klarar av att upptäcka. Det blir alltså fel, som disken aldrig märker. Dessa kallas Silent Corruption. Och alla dessa diskar kör 520 Byte. Det rapporteras även om interface errors. Inte nog med att disken blir fel, även interfacet kan orsaka fel.

Så vad är din slutsats när Fibre Channel / SAS diskar använder 520 Byte stora sektorer, varav 8 bytes är checksummor? Att det räcker med 8 byte checksummor för att allt ska vara säkert?

Visst, det kanske finns lite checksummor på diskarna så att diskarna är helt säkra (enligt dig), men tror du att det inte kan bli problem nån annanstans? Typ, man slår på disken? Det blir för varmt? Buggar i firmware? Buggar i hw-raidet? Strömspikar? Att det råkar bli högt ljud intill diskarna så att de börjar vibrera kraftigt?
http://www.youtube.com/watch?v=tDacjrSCeq4

Jag fattar inte. CERN säger att de gjorde en stor studie på sina hw-raid och att allt såg bra ut, men sen gick CERN igenom varje bit och upptäckte massa fel. CERNs slutsats var att även mycket dyra Enterprise lösningar råkar ut för dessa problem - oberoende av pris. Låt mig ta det igen, även mycket dyra Enterprise lagringslösningar råkar ut för dessa problem - oavsett prisklass. CERN säger; lita aldrig på hårdvaran. Datorer går sönder. Det finns buggar i all mjukvara, etc. Det spelar ingen roll hur mycket checksummor du har på disken om det är buggar i firmware eller om det är höga ljud bredvid disken eller whatever. Det hoppas jag du inser.

Problemet är att det är checksummor på en domän, men inga checksummor över olika domäner. Det görs kontroller på själva disken, men tänk om interfacet korruptade data? Eller RAM? Det görs inga kontroller tvärs över domäner. Det är inga end-to-end checksummor som görs, dvs från början (RAM) till slut (diskens yta).

Vidare, anta att det blir fel mycket sällan. Spec sheet på Fibre Channel och SAS diskar, rapporterar 1 fel per 10^16 bit. Det är fel väldigt sällan? Nej. Anta att du reparerar ett raid, en disk gick sönder. Eftersom du flyttar flera TB data, och det är 1 på 10^16 att det blir fel, så är det typ 25% chans att det blir fel minst en gång när du reparerar en disk. Risken är liten, men eftersom du gör så väldigt många läsningar så blir risken hög till slut. Det är väldigt liten risk att träffas av blixten, men förr eller senare sker det eftersom blixten slår ned så många ggr i Sverige per år.

Trots all forskning så finns det ändå folk som säger att de aldrig råkar ut för data korruption. Mycket märkligt säger jag. De behöver inte heller ECC RAM minnesstickor, antar jag, eftersom deras servrar aldrig kraschat. Endast när allting kraschar och jorden går under, så märker man datakorruption. Alternativt att en blå smurf dyker upp och säger "GNAPP" bredvid Fibre Channel diskarna - men eftersom folk inte sett några såna smurfar så har folket aldrig råkat ut för data korruption. Vet ni vad, jag har aldrig sett eller blivit biten av en Isbjörn - alltså kan de inte finnas. Får man inga problem såsom bitmärken (krascher), så existerar det inte. Eller hur?

Jag vet inte vad jag kan göra mera. Jag har länkat till massa forskning, studier, lagringsexperter, etc och även folk som berättar om data korruption - om allt detta inte duger så finns det inte så mycket mera jag kan göra. Vanligtvis brukar folk acceptera forskning och studier, men om man vägrar all forskning så går det inte att göra mer.

Här är det NetApp tillsammans med två universitet som studerade Data corruption under nästan 4 år, och såg data corruption på 760 Fibre Channel diskar, och på 3,100 SATA diskar. NetApp anses väl some en high end lagringslösning och de fick massa silent data corruption.
http://oss.oracle.com/~mkp/docs/data-integrity-webcast.pdf
Men jag antar väl att NetApp inte heller är ett argument att Silent Data corruption förekommer. NetApp är väl amatörer, precis som CERN, antar jag.

Angående ZFS single point of failure, ZFS skalar inte, etc.

Single point of failure. Om detta är viktigt, så gör man som Thumper x4500 servrar: Man har, säg 8st kontroller kort, A-H. Till varje kort kopplar man 8 diskar.
kort A: disk1, d2, d3, d4, d5, d6, d7, d8
kort B: disk1, d2, d3, d4, d5, d6, d7, d8
...
kort H: disk1, d2, d3, d4, d5, d6, d7, d8

Nu skapar man ett raidz2 (raid-6) utav alla "disk1", dvs en rak linje nedåt. Sen skapar man en raidz2 utav alla "d2", etc. Alla dessa åtta stycken raidz2 sätts ihop till ett ZFS raid. Antag nu att 2 kort kraschar, t.e.x "kort A" och "kort H", då är det inga problem, eftersom alla raidz2 kör vidare. Men antag nu att man kör hw-raid och det kortet kraschar - ja, då är det ett single point of failure. Eftersom ett ZFS raid spänner över alla kontrollerkort och diskar på servern så är hw-raid mer utsatt för single-point-of-failure än ZFS. Jag förstår inte alla klagomål om single-point-of-failure när hw-raid har det i mycket högre grad.

Angående att ZFS inte skalar, jag tycker det är fel att påstå att ett hw-raid kort med 0,8 GHz PowerPC och 0,5GB RAM skalar bättre en server med flera quad Xeon cpuer med 128GB RAM, flera kontrollerkort och hundratalet diskar. Sant är att ZFS inte skalar utåt (pga det är ej klustrat) men ett hw-raid kort skalar inte heller utåt, du måste istället lägga på mjukvara ovanpå hw-raidet som gör det åt dig. ZFS skalar uppåt mycket bra (uppgradera till en starkare server), men inte utåt (ej klustrat). hw-raid skalar varken uppåt eller utåt. Du kan inte uppgradera hw-raid kortet. Du kan inte köra det i kluster. Så jag tycker det är menlöst att säga att ZFS har skalningsproblem, men att ett hw-raid kort inte har skalningsproblem. Ett hw-raid har också en cpu som kommer att flaska till slut, skillnaden är att en ZFS server har ett gäng Quad Xeon cpuer och flaskar mycket senare. Om det är någon som har skalningsproblem så är det en 800MHz cpu på ett ensamt hw-raid kort som har det.

Sen beskrev jag ett scenario där en switch mellan klientdatorn och SAN storageservern, var trasig och ZFS detekterade data korruption. Jag skrev även att SANet körde ZFS men det var fel, ZFS kördes på klientdatorn. SANet hade delat ut en rå partition med iSCSI, som användaren sen importerade som en lokal disk och formaterade med ZFS. När användaren lagrade data på SANet, så detekterade ZFS felen som uppstod pga trasig switch som satt mitt emellan klientdatorn och SANet. Ingen visste att switchen var buggig, ZFS var den enda som märkte det.

Det finns även trådar i Solaris forum när SANet delar ut en iSCSI partition och användaren formaterar LUN med ZFS, och sen klagar användaren på buggar i ZFS, eftersom ZFS rapporterar datakorruption. Användaren sket i att köra ZFS raid, eftersom SANet körde raid funktionalitet och var "säkert". När ZFS började rapportera korrupta filer undrade användaren hur man kan återställa filerna, pga buggar i ZFS. Men det egentliga problemet var att SANet korruptade data, men ingen hade fått rapport om det tidigare. SANet var alltså osäkert och korruptade data. Återigen var ZFS den enda som märkte det.

Jag har mycket svårt att se hur ett hw-raid kort med 520 bytes Fibre Channel diskar skulle göra lika bra ifrån sig här. Mest troligt skulle hw-raidet inte märkt något alls, utan bara kört på och rapporterat "inga fel".

Skrivet av BarreGargamel:

Jag upptäckte till min stora glädje att vi kan kompliera linuxkärnan med CONFIG_BLK_DEV_INTEGRITY aktiverat för att kunna "native" i vår linuxkernel nyttja 520 bytes formatering på SCSI devices (som jag förstått det) och kan alltså skydda oss från det du kallar för bitröta på SAMTLIGA filsystem som linux supportar, XFS, ext3, ext4 och till och med gamla filsystem som fat32.. och det utan HW-raid alltså...

Ja detta med T10 DIF och DIX är ett steg i rätt riktning. Dock är detta något nytt, bara några år gammalt. Efter att Sun gjorde något åt data korruption med ZFS för 10 år sen, och att Oracle köpte upp Sun, så har nu Oracle varit pådrivande i detta. Oracle har lärt sig att det finns en poäng att använda end-to-end checksummor som ZFS gör, för då kan man detektera väldigt många fel som inte går annars.

Dock återstår att se hur väl detta är implementerat. Det finns ingen forskning på detta än. Det finns ju checksummor överallt, men det blir inte säkrare för det. Men som sagt, detta är ett steg i rätt riktning. Oracle inser fördelarna med checksummor end to end efter att de köpte upp ZFS och är nu pådrivande i detta och skriver massa kod för det, kod som hjälper dig.
http://oss.oracle.com/~mkp/docs/data-integrity-webcast.pdf

mats42,
Du påstår att hw-raid är säkra och skyddar mot silent corruption, men du vill inte ge några länkar eller andra bevis som stödjer det du påstår. Du inser väl att det inte är vidare trovärdigt? På det sättet övertygar man ingen "trust me, I am a doctor"? Istället ber du MIG att hitta länkar åt dig. Jag menar att det inte finns några såna länkar, därför kan du inte posta såna länkar. Jag kommer inte heller hitta såna länkar, eftersom de inte existerar. Det är alltså lönlöst att varken du eller jag letar, eftersom du har fel. hw-raid är inte alls säkert, det visar forskning som jag länkat till. Om du hittar länkar som säger motsatsen så är det fel nånstans. Antingen har forskarna fel (mindre troligt) eller så har IBMs reklamblad fel (högst troligt). Du kommer bara kunna posta IBMs reklamblad, men ingen seriös forskning.

Sen använder du även andra argumentationstekniker såsom "jasså, du driftar inga system, ja då kan du ju inget" - typ. Det är inte heller trovärdig argumentation till varför all forskning jag länkar till ska avvisas.

Om du nu påstår massa starka saker så kan du väl argumenterar för det på något sätt, istället för att be mig lita på dig, med hänvisning till att du driftat 300 raidsystem? Helst bör du posta länkar till forskare.

Sen om hw-raid är på väg bort eller ej. Ett par verkar överens om att hw-raid betydelse kommer att minska, att mjukvaruraid såsom BTRFS och ZFS kommer att vinna mark. Sen finns det folk som pratar om Fibre Channel lösningar, etc - men det är väl knappast low end hw-raid kort det. Snarare är vi inne på high end lösningar som är dyra. Men disksussionen handlar ju inte om high end lösningar. Det finns ju stora lösningar för flera miljoner som påstås kunna än det ena och det andra, men som CERN säger: även de har brister i skyddet. Men det uttalandet får stå för CERN, jag har inte sett forskning på high end lösningar, annat än den forskning som CERN har gjort.

Jag tror fortfarande att vanliga hw-raid kort kommer att försvinna till förmån för ZFS och BTRFS. Visst kommer det alltid finnas kvar dyra speciallösningar, men det är inte det vi diskuterar.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av saddam:

Här har vi Fibre Channel diskar med såna 520 bytes block du pratar om.
http://www.seagate.com/staticfiles/support/disc/manuals/enter...
Fibre Channel Cheetah 10K.7 FC diskar har 520 byte stora sektorer och rapporterar felfrekvens i kapitel 5.0, där pratas om felfrekvenser för "Recovered Data", "Unrecovered Data" och även "Miscorrected data" - dvs data som reparerades men blev helt fel.

http://www.seagate.com/staticfiles/support/disc/manuals/enter...
Kapitel 5.1.2 säger att denna 520 byte formaterade SAS enterprise disk, råkar ut för fel som inte går att reparera.

Seagate Barracuda ES.2 SAS diskar med 520 Byte stora sectorer inkl checksummor, rapporterar samma felfrekvens, dvs 1 sector blir fel per 10^15.

Så vi ser här några exempel på SAS Enterprise diskar och Fibre Channel Diskar som alla har problem med fel som de inte kan reparera, eller reparerar helt fel. Det som INTE står i Spec sheeten dock, är alla fel som inte disken klarar av att upptäcka. Det blir alltså fel, som disken aldrig märker. Dessa kallas Silent Corruption. Och alla dessa diskar kör 520 Byte. Det rapporteras även om interface errors. Inte nog med att disken blir fel, även interfacet kan orsaka fel.

Så vad är din slutsats när Fibre Channel / SAS diskar använder 520 Byte stora sektorer, varav 8 bytes är checksummor? Att det räcker med 8 byte checksummor för att allt ska vara säkert?

Visst, det kanske finns lite checksummor på diskarna så att diskarna är helt säkra (enligt dig), men tror du att det inte kan bli problem nån annanstans? Typ, man slår på disken? Det blir för varmt? Buggar i firmware? Buggar i hw-raidet? Strömspikar? Att det råkar bli högt ljud intill diskarna så att de börjar vibrera kraftigt?
http://www.youtube.com/watch?v=tDacjrSCeq4

Jag fattar inte. CERN säger att de gjorde en stor studie på sina hw-raid och att allt såg bra ut, men sen gick CERN igenom varje bit och upptäckte massa fel. CERNs slutsats var att även mycket dyra Enterprise lösningar råkar ut för dessa problem - oberoende av pris. Låt mig ta det igen, även mycket dyra Enterprise lagringslösningar råkar ut för dessa problem - oavsett prisklass. CERN säger; lita aldrig på hårdvaran. Datorer går sönder. Det finns buggar i all mjukvara, etc. Det spelar ingen roll hur mycket checksummor du har på disken om det är buggar i firmware eller om det är höga ljud bredvid disken eller whatever. Det hoppas jag du inser.

Problemet är att det är checksummor på en domän, men inga checksummor över olika domäner. Det görs kontroller på själva disken, men tänk om interfacet korruptade data? Eller RAM? Det görs inga kontroller tvärs över domäner. Det är inga end-to-end checksummor som görs, dvs från början (RAM) till slut (diskens yta).

Vidare, anta att det blir fel mycket sällan. Spec sheet på Fibre Channel och SAS diskar, rapporterar 1 fel per 10^16 bit. Det är fel väldigt sällan? Nej. Anta att du reparerar ett raid, en disk gick sönder. Eftersom du flyttar flera TB data, och det är 1 på 10^16 att det blir fel, så är det typ 25% chans att det blir fel minst en gång när du reparerar en disk. Risken är liten, men eftersom du gör så väldigt många läsningar så blir risken hög till slut. Det är väldigt liten risk att träffas av blixten, men förr eller senare sker det eftersom blixten slår ned så många ggr i Sverige per år.

Trots all forskning så finns det ändå folk som säger att de aldrig råkar ut för data korruption. Mycket märkligt säger jag. De behöver inte heller ECC RAM minnesstickor, antar jag, eftersom deras servrar aldrig kraschat. Endast när allting kraschar och jorden går under, så märker man datakorruption. Alternativt att en blå smurf dyker upp och säger "GNAPP" bredvid Fibre Channel diskarna - men eftersom folk inte sett några såna smurfar så har folket aldrig råkat ut för data korruption. Vet ni vad, jag har aldrig sett eller blivit biten av en Isbjörn - alltså kan de inte finnas. Får man inga problem såsom bitmärken (krascher), så existerar det inte. Eller hur?

Jag vet inte vad jag kan göra mera. Jag har länkat till massa forskning, studier, lagringsexperter, etc och även folk som berättar om data korruption - om allt detta inte duger så finns det inte så mycket mera jag kan göra. Vanligtvis brukar folk acceptera forskning och studier, men om man vägrar all forskning så går det inte att göra mer.

Här är det NetApp tillsammans med två universitet som studerade Data corruption under nästan 4 år, och såg data corruption på 760 Fibre Channel diskar, och på 3,100 SATA diskar. NetApp anses väl some en high end lagringslösning och de fick massa silent data corruption.
http://oss.oracle.com/~mkp/docs/data-integrity-webcast.pdf
Men jag antar väl att NetApp inte heller är ett argument att Silent Data corruption förekommer. NetApp är väl amatörer, precis som CERN, antar jag.

Angående ZFS single point of failure, ZFS skalar inte, etc.

Single point of failure. Om detta är viktigt, så gör man som Thumper x4500 servrar: Man har, säg 8st kontroller kort, A-H. Till varje kort kopplar man 8 diskar.
kort A: disk1, d2, d3, d4, d5, d6, d7, d8
kort B: disk1, d2, d3, d4, d5, d6, d7, d8
...
kort H: disk1, d2, d3, d4, d5, d6, d7, d8

Nu skapar man ett raidz2 (raid-6) utav alla "disk1", dvs en rak linje nedåt. Sen skapar man en raidz2 utav alla "d2", etc. Alla dessa åtta stycken raidz2 sätts ihop till ett ZFS raid. Antag nu att 2 kort kraschar, t.e.x "kort A" och "kort H", då är det inga problem, eftersom alla raidz2 kör vidare. Men antag nu att man kör hw-raid och det kortet kraschar - ja, då är det ett single point of failure. Eftersom ett ZFS raid spänner över alla kontrollerkort och diskar på servern så är hw-raid mer utsatt för single-point-of-failure än ZFS. Jag förstår inte alla klagomål om single-point-of-failure när hw-raid har det i mycket högre grad.

Angående att ZFS inte skalar, jag tycker det är fel att påstå att ett hw-raid kort med 0,8 GHz PowerPC och 0,5GB RAM skalar bättre en server med flera quad Xeon cpuer med 128GB RAM, flera kontrollerkort och hundratalet diskar. Sant är att ZFS inte skalar utåt (pga det är ej klustrat) men ett hw-raid kort skalar inte heller utåt, du måste istället lägga på mjukvara ovanpå hw-raidet som gör det åt dig. ZFS skalar uppåt mycket bra (uppgradera till en starkare server), men inte utåt (ej klustrat). hw-raid skalar varken uppåt eller utåt. Du kan inte uppgradera hw-raid kortet. Du kan inte köra det i kluster. Så jag tycker det är menlöst att säga att ZFS har skalningsproblem, men att ett hw-raid kort inte har skalningsproblem. Ett hw-raid har också en cpu som kommer att flaska till slut, skillnaden är att en ZFS server har ett gäng Quad Xeon cpuer och flaskar mycket senare. Om det är någon som har skalningsproblem så är det en 800MHz cpu på ett ensamt hw-raid kort som har det.

Sen beskrev jag ett scenario där en switch mellan klientdatorn och SAN storageservern, var trasig och ZFS detekterade data korruption. Jag skrev även att SANet körde ZFS men det var fel, ZFS kördes på klientdatorn. SANet hade delat ut en rå partition med iSCSI, som användaren sen importerade som en lokal disk och formaterade med ZFS. När användaren lagrade data på SANet, så detekterade ZFS felen som uppstod pga trasig switch som satt mitt emellan klientdatorn och SANet. Ingen visste att switchen var buggig, ZFS var den enda som märkte det.

Det finns även trådar i Solaris forum när SANet delar ut en iSCSI partition och användaren formaterar LUN med ZFS, och sen klagar användaren på buggar i ZFS, eftersom ZFS rapporterar datakorruption. Användaren sket i att köra ZFS raid, eftersom SANet körde raid funktionalitet och var "säkert". När ZFS började rapportera korrupta filer undrade användaren hur man kan återställa filerna, pga buggar i ZFS. Men det egentliga problemet var att SANet korruptade data, men ingen hade fått rapport om det tidigare. SANet var alltså osäkert och korruptade data. Återigen var ZFS den enda som märkte det.

Jag har mycket svårt att se hur ett hw-raid kort med 520 bytes Fibre Channel diskar skulle göra lika bra ifrån sig här. Mest troligt skulle hw-raidet inte märkt något alls, utan bara kört på och rapporterat "inga fel".

Ja detta med T10 DIF och DIX är ett steg i rätt riktning. Dock är detta något nytt, bara några år gammalt. Efter att Sun gjorde något åt data korruption med ZFS för 10 år sen, och att Oracle köpte upp Sun, så har nu Oracle varit pådrivande i detta. Oracle har lärt sig att det finns en poäng att använda end-to-end checksummor som ZFS gör, för då kan man detektera väldigt många fel som inte går annars.

Dock återstår att se hur väl detta är implementerat. Det finns ingen forskning på detta än. Det finns ju checksummor överallt, men det blir inte säkrare för det. Men som sagt, detta är ett steg i rätt riktning. Oracle inser fördelarna med checksummor end to end efter att de köpte upp ZFS och är nu pådrivande i detta och skriver massa kod för det, kod som hjälper dig.
http://oss.oracle.com/~mkp/docs/data-integrity-webcast.pdf

mats42,
Du påstår att hw-raid är säkra och skyddar mot silent corruption, men du vill inte ge några länkar eller andra bevis som stödjer det du påstår. Du inser väl att det inte är vidare trovärdigt? På det sättet övertygar man ingen "trust me, I am a doctor"? Istället ber du MIG att hitta länkar åt dig. Jag menar att det inte finns några såna länkar, därför kan du inte posta såna länkar. Jag kommer inte heller hitta såna länkar, eftersom de inte existerar. Det är alltså lönlöst att varken du eller jag letar, eftersom du har fel. hw-raid är inte alls säkert, det visar forskning som jag länkat till. Om du hittar länkar som säger motsatsen så är det fel nånstans. Antingen har forskarna fel (mindre troligt) eller så har IBMs reklamblad fel (högst troligt). Du kommer bara kunna posta IBMs reklamblad, men ingen seriös forskning.

Sen använder du även andra argumentationstekniker såsom "jasså, du driftar inga system, ja då kan du ju inget" - typ. Det är inte heller trovärdig argumentation till varför all forskning jag länkar till ska avvisas.

Om du nu påstår massa starka saker så kan du väl argumenterar för det på något sätt, istället för att be mig lita på dig, med hänvisning till att du driftat 300 raidsystem? Helst bör du posta länkar till forskare.

Sen om hw-raid är på väg bort eller ej. Ett par verkar överens om att hw-raid betydelse kommer att minska, att mjukvaruraid såsom BTRFS och ZFS kommer att vinna mark. Sen finns det folk som pratar om Fibre Channel lösningar, etc - men det är väl knappast low end hw-raid kort det. Snarare är vi inne på high end lösningar som är dyra. Men disksussionen handlar ju inte om high end lösningar. Det finns ju stora lösningar för flera miljoner som påstås kunna än det ena och det andra, men som CERN säger: även de har brister i skyddet. Men det uttalandet får stå för CERN, jag har inte sett forskning på high end lösningar, annat än den forskning som CERN har gjort.

Jag tror fortfarande att vanliga hw-raid kort kommer att försvinna till förmån för ZFS och BTRFS. Visst kommer det alltid finnas kvar dyra speciallösningar, men det är inte det vi diskuterar.

Gå till inlägget

Att du inte förstår, det förstår jag. Först hävdar du att raid är i princip livsfarligt men konstigt nog har vi inte sett det problemet. Du hävdar då att det inte märks utan checksummor. I verkligheten märks ett korrupt raidset om du försöker byta en trasig disk mot en ny då systemet inte kan göra rebuild men det inträffar som sagt inte. (normalt har man dessutom en online spare som bygger upp direkt). Angående checksummorna så fick du även exempel på både HW och SW system som använder dem. Återigen utan att de larmar .

Sen har du fortfarande inte publicerat en enda länk som specar vilken kontroller det var man hadde fel med. Utan det så går det inte att dra en enda slutsats.

Du påstod ju att windows var så mycket känsligare på dåligt minne men du har ju inte visat någo grund för det trots att jag har bett dig två gånger om att förklara hur UNIX ska läsa data från ett korrupt minne.

Du har heller inte förklarat hur du ska skriva på ständigt nya platser utan att disken blir full.

Svaret på hur du ska lösa block-I/O saknas också.

Eftersom du hävdade att man bara tjänade 10% på writecache så fick du ett exempel som visar att 10 gånger är mer rätt.

När du hävdade att det bara var ZFS som kunde upptäcka en trasig switch så fick du delar av Ethernet specifikationen som svar. Där framgår klart att det hanteras redan på protokollnivå i Ethernet och därmed inte behöver hanteras längre upp.

Sen tycker du något om Raidkontrollers igen utan att ha någon som helst erfrehet av någon och eftersom prioduktblad inte duger åt dig så har du ju just sagt att du inte tänker lyssna på någon som visar att du har fel där heller.

Och återigen så verkar du inte förstå att direktanslutna diskar ger högre I/O last än diskar via Smarta kontrollers. Därmed kommer ett moderkort att få skalningsproblem långt innan en kontroller får det. I dit senaste exempel så ska moderkortet göra 64 anrop istället för ett för kontrollera diskstatus tex.
Vad tror du merkosntanden blir för att göra något 64 gånger inefektivare? HW kontrollern gör jobet med dedikerad hårdvara och därmed behöver den CPU:n inte slita för att göra jobet

När det gäller dokumentation får du samma svar igen. Vill du lära dig får du leta eller plugga. En bra utbildning som dessutom tar upp I/O och moderkortsdesign är HP/Compaqs ASE utbildning http://www.hp.com/certification/expert_one-intermediate.html. , IBM:s motsvarighet hette PSE när jag tog den. Vi är nu två som båda säger samma sak, dokumenten finns men är ej publika och jag tänker fortfarande inte begå avtalsbrott för dig, I synnerhet när du antyder att du ändå inte tänker tro på något som du inte anser är en forskningsrapport

Sen är det ju bara konstatera att det var du som började skrika om att fibrechannel system minnsan inte kunde upptäcka fel de heller. Och återigen så jo det kan de men tyvärr är nog varken Ciscos eller brocades specar publika de heller.

Först säger du att ZFS är en enterprise lösning och sen säger du att det är fel att prata high-end. Enterprise lösningar är High-end system. Du tycker att Raidkontrollers är dyra men att lägga ut några hundra tusen på större servrar, det ser du inga problem med. Inte heller med den extra plats de tar eller den strömförbrukning extra de glufsar i sig?

Det är just här den stora skillanden märks mellan oss. Vi är minst tre personer i denna tråd som jobbar med stora system dagarna i ända. Två med drift och en leverantör av mycket högpresterande lagringssystem som hanterar väldigt mycket och väldigt känsligt data. Du har ingen som helst erfarenhet att väga mot de rapporter du läser och därmed verkar de ha blivit din heliga Graal. Vi har erfarenheter och annan information att väga det emot. Om en rapport säger att vi skulle ha X antal tusen korrupta filer och vi inte har det så kan man ju börja fundera på om leverantörsspecen som säger att de har skydd mot det stämmer eller om vi bara har en rent otrolig tur. Iom storleken på system och att vi är fler med samma erfarenhet så kan man nog stryka turen och då finns det två alternativ kvar. Systemen är skyddade eller risken är extremt överdriven.

Senast redigerat
Visa signatur

Arbetsdator: HFX Mini. Ryzen 3600, GTX1650. Skärmar: Dell 2415

Redigera
Citera flera Citera
1 2 3 4 5
Skriv svar