OpenSolaris 2009.06 är här!

1. Jag tror inte man med "trygghet" kan köra sunkdiskar eftersom alla diskar kanske kraschar snart. Men om de inte skulle krascha så skulle jag utan tvekan kunna köra sunkdiskar med ZFS. Men det måste vara raidz, förstås.

2. ZFS detekterar alla fel och talar om att du har problem. Det märker du när du begär status rapport "zpool status".

pool: TempStorage
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
TempStorage ONLINE 0 0 0
c7d0p4 ONLINE 0 0 0 <---------------- här detekteras bl.a. silent corruption

errors: No known data errors" <-------------- här detekteras bl.a. silent corruption

Skälet till att ZFS kan detektera felen är att det är end-to-end checksums. Dvs, ZFS jämför alltid början med slutresultatet. Dvs, datat i RAM och datat på disk - blev det lika? Det sker en jämförelse mellan kedjans början och kedjans slut, dvs end-to-end. Andra filsystem jämför inte end-to-end. De skickar ned data från RAM till disk kontrollern - och litar på att det går bra. Men antag att det är BIOS buggar i disk kontrollern? Det finns flera lager i lagringsstacken, grovt finns: RAM ned till kort, kort ned till disk. Egentligen finns det många fler lager. Det var nån studie från... CISCO(?) som visade att packade data kan komprimeras och dekomprimeras runt 7 gånger på väg ned till disk, från RAM. Det kan bli fel när data passerar olika lager. Men ZFS jämför hela tiden RAM mot slutresultatet. End-to-end. Ingen annan gör just detta, dvs kontroll mellan olika lager från början till slut.

3. Nej, silent corruption loggas inte av ZFS, men du när du skriver "zpool status" så ser du alla fel som uppstod och som reparerades (inkl fel med silent corruption). De s.k. "forskarna" du pratar om: de forskar i datavetenskap och har artificiellt introducerat massa fel i ZFS. Dvs, error injection på olika knepiga sätt - och ZFS detekterade alla fel utan problem (pga end-to-end checksums). Men ZFS lyckades inte reparera alla felen pga forskarlaget inte körde raidz.

I andra studier så har XFS, JFS, ReiserFS, etc inte ens lyckats detektera alla fel som injicerades. Än mindre reparera felen. Det viktigaste är att detektera felen - för hur ska du annars känna till att det finns något att reparera?

Mao, anser jag inte att dessa forskningsresultat är värdelösa. ZFS är robust mot många fel och detekterar alla fel som provocerades fram - men forskarna visade att om man korruptar datat i RAM så är ZFS chanslös. Men det är naturligt - ZFS garanterar bara att det som får in, skrivs ned korrekt. ZFS kontrollerar inte om datat som ska sparas ned är korrekt. Så forskarnas slutsats är att man MÅSTE köra ECC RAM tillsammans med ZFS. Därför att RAM är svagaste länken i kedjan. När väl ZFS fått tag i datat så är det säkert. Men innan ZFS fått tag i datat så behöver du ECC. (Det visar sig att inte ens ECC är 100% säkert, det finns bättre RAM-tekniker, men det är dyrare).

Jag har länkat till dessa forskningsartiklar tidigare. Det är bara att läsa dem.

4. ZFS bygger aldrig om allting i onödan. ZFS bygger endast om de data som fattas. Mao kan det gå snabbt att reparera raidet. Mao, så har du inte samma problem i ZFS: där du bygger om hela disken från scratch.

Det har klagats på implementationen av fletcher2 förrut, t.ex.
OpenSolaris Forums : fletcher2/4 implementations ...
Och detta fixades förrut i b114
Bug ID: 6740597 zfs fletcher-2 is losing its carries

Om du verkligen är nojjig så kan du ställa in att default checksumme algoritm är SHA-256 när du beräknar säkerhet.
# zfs set checksum=sha256 dataset
Detta är ett av skälen till att ZFS är lite långsammare än andra filsystem. De andra filsystemen gör inte alls lika många beräkningar för att kontrollera data integriteten. Ju fler beräkningar, desto långsammare, men desto även säkrare. Det går åt 1GHz cpu för att beräkna checksummor för 500MB/sek med fletcher2 - det är alltså ganska snabbt och är effektivt. SHA-256 skulle dra mer kraft. Man måste göra avvägning.

Checksummorna som weeblie pratar om här, fletcher2, används inte för att kolla kollisioner (vilket görs i dedup). Mao, är det inte alls lika höga krav för dessa checksummor för säkerhet, som det är i dedup. I dedup är kraven höga eftersom det används för att hitta kollisioner mellan två liknande datablock. Dessa höga krav ser vi av att SHA-256 är standard i dedup. Tidigare var det fletcher4 som var standard i dedup men det hade brister eftersom det kunde faktiskt generera kollisioner (även om sannolikheten var mycket låg).
OpenSolaris Forums : Dedup - Does "on" imply "sha256?" ...

Mao, att man använder fletcher2 (som kan generera kollisioner) är inte vidare stort problem, när du beräknar säkerhetschecksummor. Kollisioner är illa om du försökte göra dedup, dock (därför finns "verify=on" då dedup jämför varje bit efter att kollision har konstaterats, så därför är inte kollisioner något problem heller i dedup). Men alla Enterprise server hallar kör ju standard checksummealgoritm, vad jag vet. Så det verkar inte vara något problem.

Ronnylov, jag tror du måste kopiera om filerna. Skapa en ny zfs dataset och kopiera dit filerna.

    134 void
    135 fletcher_2_native(const void *buf, uint64_t size, zio_cksum_t *zcp)
    136 {
    137 	const uint64_t *ip = buf;
    138 	const uint64_t *ipend = ip + (size / sizeof (uint64_t));
    139 	uint64_t a0, b0, a1, b1;
    140 
    141 	for (a0 = b0 = a1 = b1 = 0; ip < ipend; ip += 2) {
    142 		a0 += ip[0];
    143 		a1 += ip[1];
    144 		b0 += a0;
    145 		b1 += a1;
    146 	}
    147 
    148 	ZIO_SET_CHECKSUM(zcp, a0, a1, b0, b1);
    149 }

Jag hängde inte riktigt med här. Vad försöker du säga med ZFS kodutdraget? Att buggen inte alls fixades?

Men 50MB/sek för varje GHz är inte för kostsamt för en hemanvändare tycker i alla fall jag. Antag att man kör Quadcore 2GHz, då får man 8 GHz totalt. Om man siktar på 200MB/sek så blir det 4GHz som går åt till SHA-256. Då har man ändå 4GHz över.

Men det verkar som om SHA-256 är 10ggr mer prestanda krävande än fletcher-2. Intressanta siffror. Har du länk på din siffra? Min siffra på 500MB/Sek per GHz är tagen från ZFS wikin.

Jo, men dedup kör ju SHA-256 så det är mycket svårt att hitta datablock som ger samma checksumma.

Hur menar du att det skulle vara ett större problem att nån skickar in datablock som ger samma checksumma, än att det blir kollisioner - i dedup?

Sant.

Personligen känner jag inte att dessa checksummeberäkningar med fletcher-2 är ett problem. Därför att ingen har klagat på detta i forumen. Om det skulle bli ett problem, om det skulle börja postas klagomål om tappade data - så skulle:

1) Oracle genast ta tag i det problemet. Det duger inte att kalla ZFS för Enterprise filsystem om det är fel i en enkel checksumme algoritm, då måste det genast åtgärdas. Det är bara att byta checksummealgoritm och be folk kopiera över sina data till nya zfs datasets. Det är alltså inget designproblem i ZFS. (Som folk sagt om BTRFS: "broken by design")

2) Alla gå över till SHA-256. Om jag får ut 100MB/sec så räcker det för mig personligen. Större servrar har många cpuer så de får också ut mycket bandbredd. Man kan allokera bråkdelar av cpuer till vissa tasks i Solaris.

3) Sånt problem borde upptäckts långt för flera år sen

Så checksummeberäkningen behöver inte vara vidare kryptografiskt stark, därför att ZFS inte letar efter identiska datablock när man kontrollerar data integritet. Identiska datablock letar man efter i dedup, och därför används SHA-256 i dedup. Jag personligen tror inte detta är ett problem, därför att om det vore ett problem så skulle vi set klagomål, och ZFS gänget skulle bytt algoritm för längesen.

@ronnylov
Möjligt. Men alla lagrar inte mediafiler och det borde upptäckts tidigare. T.ex. att dokument inte kan öppnas, packade filer inte kan packas upp, etc - och då skulle det blivit ramaskri "jag har fått corrupta data med ZFS!!! jag kan inte packa upp en fil!!!"

Om du endast är intresserad av att se om någon bit har ändrat på sig, så behöver du inte kryptografiskt stark hashning. Det enda fletcher2 används till, är för att detektera om några bits har ändrat på sig. För detta duger fletcher2.

I dedup så måste du identifiera identiska datablock, så det räcker inte längre med att bara hitta en bit som flippat. I dedup måste du vara säker på att du aldrig råkar säga att två datablock är identiska, av misstag. Därför används SHA-256 i dedup.

För checksumme säkerhetsberäkningar så vill du bara ta reda på om någon bit har ändrat sig. Därför använder du en hashfunktion som gör stora utslag när någon bit ändrat sig (dvs fletcher2). I dedup måste du jämföra om datablock är identiska, detta ställer högre krav på hashfunktionen som måste vara kryptografiskt stark. Därav SHA-256.

@dagle,
Jag fattar inte riktigt. Hur då mounta en hashtabell? Det låter märkligt?

Hehe, nej det tyckte inte jag var enkelt. Kan du förklara hur du ser att buggen inte fixats? Vad är det man ska kolla efter? Vad är för kodrad som strular? Det låter ju illa att ZFS utvecklarna påstår att buggen fixats, men du säger att buggen inte fixats - eftersom du ser det enkelt.

Inte en aning om vad som är standard.

Jo, jag vet. Men en enkelt överslagsräkning visar att man har gott om kraft över. Och om din "20 cykler/byte för blockstorlekar på ett par KB" benchmark som visar att 1GHz ger 50MB/sek med SHA-256 är gammal benchmark så ska den siffran revideras. Sandybridge är ju snabbare än en Pentium 4, t.ex.

Sist jag hörde så var ZFS enkeltrådat när det räknade checksummor. Men jag har inte kollat koden hur status är idag. Men det är något ZFS gänget ska ta tag i, och göra mulitrådat.

Hängde återigen inte med. Kan du förklara hur detta säger att 1GHz ger 50MB/sek för SHA-256?

Va? Var har jag antytt det? Kan du citera?

Jag hängde inte med på sista raden. Hur blev du root? Antag att du hittat ett elakt datablock som ger samma hashvärde som det riktiga, vad händer när du sparar ditt elaka datablock? Jo, det kommer att raderas eftersom det datablocket redan finns lagrat. Varför lagra ett identiskt datablock igen? Som sagt, jag hänger inte riktigt med, du är lite för snabb i vändningarna för mig.

Jag säger inte att svagheten inte finns, jag säger bara att man vill bara detektera om en bit flippats, och det är mycket enklare än att hitta identiska datablock. Men om det nu stämmer det du säger, att buggar inte fixats (trots att ZFS gänget påstås fixats) så är det illa. Om du nu har rätt om carries bitarna inte bevaras så är det bara att berätta det i ZFS forumet så får du genast mycket uppmärksamhet. Men anser du att fletcher4 är så mycket bättre att man bör köra det istället?

Jag har inte satt mig in i fletcher2. Men använder dessa ZFS hashfunktioner, tvåkomplement?

Hur kom du fram till den här siffran, har du länk? Det låter som att det är en oroväckande hög siffra.

Vad försöker du säga här? Kan du förklara lite vad du försöker säga istället för att endast visa lite kod eller en graf, utan en förklaring? Så hänger man med lite i vad du säger?

Men om det du säger stämmer (lite fler förklaringar önskas) så kanske man bör switcha till fletcher4, då?

Jo, den disten verkar kunna bli trevlig. Målet är att den ska fortsätta på OpenSolaris. OI (OpenIndiana) ska vara helt binär kompatibel med Solaris 11. Utvecklarna ska hela tiden backporta källkod från Solaris 11 och Solaris 11 Express så OI hela tiden är synkad. Idag stödjer OI numera ZFS dedup, eftersom OI utgår från b147. Snart kommer OI att bygga helt på Illumos. Man kan enkelt uppgradera från b134, bara att peka om IPS repot.

Dock är OpenIndiana buggig just nu. Jag ska vänta ett tag och när de släppt stabilare versioner så ska jag göra en ny BE och testa den. Jag tror b147 är bättre än b134.

Jag reser mycket snart och har fullt upp på jobbet. Har inte tid just nu att övertyga mig att du har rätt. Så vi kör på att du har rätt.

Detta är oroväckande det du skriver. Kanske bör även jag följa ditt råd att byta till fletcher4. Men innan jag gör så, så vill jag posta detta du påstår på opensolaris forumet, om du inte vill göra det? Detta är ju illa att man bara låter buggen vara. Det kan vara så att du inte läser koden rätt (t.ex. att indata kommer bara se ut på ett visst sätt så att man inte råkar ut för de problem du menar) eller så kan det vara att du har rätt. Då ska det uppmärksammas på forumet.

Vill du posta eller ska jag posta på opensolaris forumets ZFS del? Om du vill att jag postar, kan du skriva en kort förklaring exakt vad som är fel så översätter jag det till engelska? Det är ju illa att ingen i ZFS teamet tar detta på allvar, om nu det är sant.

Jag hänger inte med. Varför är teoretiskt max 15 cykler/byte? På wikin påstås att fletcher2 ger 500MB/sek för varje GHz. Det betyder alltså 2 cykler/byte, och du verkar mena att det är omöjligt att få köra snabbare än 15 cykler/byte (dvs 67 MB/sek)?
ZFS Evil Tuning Guide - Siwiki

Det låter vettigt. Men frågan är om din implementering verkligen är optimal? 500MB/sek är ganska mycket snabbare än 50MB/sek, vilket du fick.

Jag vet inte om verify=on är förvalt. Jag menar bara att det är dåligt att köra verify=off om du väljer en kryptografiskt svag hashfunktion

Jag tar min fråga en gång till: hur skulle du "smyga in ett elakt block"? Fattar inte. Hur kan du göra det, när det redan finns ett "identiskt" block? Ditt block borde raderas, och originalblocket som redan finns där, borde finnas kvar?

Jag postar buggen du upptäckte (där du får all cred förstås) och sen byter jag också till fletcher4, när ZFS teamet bekräftat buggen. Det är iofs enklare om du postar buggen där, istället för att jag gör det.

Ok, om du säger det så. Kan du nämna detta också? Att tvåkomplement är dålig lösning. Skriv ned ditt lösning på forumet istället.

Skriv ned detta också i forumet, är du snäll. Jag hinner inte övertyga mig att du har rätt, har mycket just nu. Men man borde sitta med olika indata, och exekvera algoritmen och se att du har rätt - och det är detta jag inte har tid med just nu. Men vi kör på att du har rätt, så en tydlig buggrapport vore nog bra.

Det ligger väl även i ditt intresse att ZFS blir säkrare, så då är det bra med en enkel och tydlig buggrapport som pekar ut felen så kan ZFS bli bättre. Det tjänar vi alla på, även vi här på forumet.

Om jag postar en länk med massa text utan att förklara mer vad man ska titta efter, är det inte lite intetsägande? Jag menar bara att du kunde lagt till en förklarande snutt, typ "här ser vi att SHA-256 är hälften så snabbt som fletcher 2". En sån kort förklaring underlättar mycket.

En fråga: om nu SHA-256 är hälften så snabbt som fletcher2 (som uppnår 500MB/sek) så borde SHA-256 uppnå 250MB/sek för varje GHz? Och inte alls 50MB/sek?

Ronnylov, har du lust att ta tid senare på SHA-256 och fletcher2 - och se hur mycket tid det skiljer?

Intressanta siffror. Tack för den infon!

Jag är inte riktigt övertygad att byta till fletcher4 än. Jag tror det vore trevligt att få problemet bekräftat via annanstans också, alternativt kontrollera saken själv (vilket vore det bästa förstås). Tänk om weeblie har varit lite för snabb med slutsatsen? T.ex. det kommer bara viss indata till fletcher2 som gör att algoritmen aldrig spårar ur på det sätt som han beskriver?

Men, jag håller med om att det låter som att weeblie vet vad han pratar om här, därför är det värt att ta det han säger på allvar och därför vill jag kolla upp detta mera. Det är klart, får man ingen bekräftelse så är det nog klokt att byta till fletcher4.

Ok, så du menar att problemet kan ha fixats på detta sätt? Dvs, man byter standardvalet till fletcher4 och låter fletcher2 vara utan några fixar? Det skulle kunna vara en vettig lösning. Men då borde man kolla detta. Skapa ett ny zfs filsystem och sen kolla vilken hash funktion som är standard: fletcher2 eller fletcher4. Om det är fletcher2 som är standard så postar jag en fråga på opensolaris forumet om ZFS.

Jo, men vad hände efter posten? Diskussionen är några år gammal. Har något ändrats än? Har problemet med fletcher2 fixats? Eller har de bara ändrat default till fletcher4? Om de ändrat default så betyder det antagligen att du har rätt när du säger att "fixen" var att byta default och de sket i att korrigera fletcher2.

Ah, ok nu förstår jag. Du menar att teoretisk max för SHA-256 är 15 cykler/byte? Och denna siffra har du fått fram genom att räkna antal operationer som SHA-256 gör? Det är alltså omöjligt att få snabbare än 67MB/sek per GHz, menar du? Det är max man kan nå?

En fråga: det finns ju instruktioner i t.ex. x86 som opererar på massa bytes samtidigt (t.ex. videogrejer). Kan man inte använda dem till SHA-256? T.ex. antag att man implementerade SHA-256 i x86 så att den opererade på 20 bytes i taget under en enda klockcykel? (T.ex. har ju Niagara Ultrasparc SHA-256 direkt i chippet så den får mycket hög genomströmning - där är det inte 20 cykler per byte. Utan kanske 20 byte på en cykel?)

Ok, då förstår jag hur du menar. Det låter vettigt det du säger, och ytterligare ett skäl att använda ett kryptografiskt starkt protokoll.

Jo, men sen är det frågan om jag har tid att undersöka bilden, och det är även frågan om vad du försöker säga. Ska jag posta en random bild så du har inte en aning om vad jag försöker säga med bilden? Ett tips, om du försöker få dina läsare att acceptera din poäng, så är det bra om du är lite tydlig och pekar ut exakt vad du menar? Det är inte så bra att t.ex. posta massa länkar med massa text och be läsarna dra samma slutsatser som du dragit, utan att ens berätta vilka slutsatser som du tycker är intressanta för din ståndpunkt.

En fråga: är det ditt eget raid eller är det siffror du hittat på nätet?

Ok, det var bättre och tydligare. Så du försöker säga att SHA-256 är långsamt. Ok, det köper jag (det är för övrigt välkänt att SHA-256 är långsamt). Det skulle inte vara så svårt att skriva att "här ser vi att SHA-256 är långsamt"? Jag kanske trodde du pratade om fletcher2 och tittade massor på fletcher2 och inte kom fram till den slutsats du ville jag skulle dra (som egentligen handlade om SHA-256)? Mao, det som är tydligt för dig, är inte alltid tydligt för andra? Kanske bättre att vara övertydlig på nätet?

Har inte kollat länkarna, men om länkarna säger det du påstår, så tycker jag det visar att Weeblie hade rätt i mycket av det han sade. Bra påpekande av Weeblie tycker jag. Tack för att du är kritisk och berättar om brister, weeblie! Det tjänar vi alla på.

Jag har ju en gammal zfs raid. Undrar om det är fletcher2 eller fletcher4? Efter weeblie, så vill jag gärna ta reda på vilken hashalgoritm min zfs raid använder. Hur gammal är min zfs raid? Man borde kunna kolla vilken zfs version som b114 använder i nån lista, och sen kolla sin egen zfs raid med "zfs version"(?). Om "zfs version" säger att jag har version 18 och om b114 använder version 19 så måste jag kopiera alla mina data till nya zfs filsystem.