Toshiba släpper hårddisk på 14 terabyte

Trädvy Permalänk
Medlem
Registrerad
Aug 2017
Skrivet av Dimman:

Som jag nämnde i min post så såg jag hans foruminlägg som ett hypotetiskt worstcase.

Om data in till ZFS är korrupt så kommer korrupt data skrivas till disk, så är det. ZFS har ingen magisk kraft att förutspå vad datat egentligen borde ha varit, därav rekommendationen att köra ECC-minnen för att minska risken för bitfel från det att det lämnar sändaren tills det skrivits ner av ZFS.

Jag orkar inte gräva mig in i implementationen men kortfattat så:
Vid detekterad missmatchning i checksummeringen letar ZFS efter ett block/paritet som gör att checksummeringen går igenom. Om det är så att ZFS hittar det och den "rätta datan" vid något skede sedan hanteras av det felaktiga RAM'et efter checksummeringskontrollen så finns det en risk för mer korruption än tidigare. Att det sen fortfarande är väldigt hypotetiskt spelar ingen roll, det skulle kunna hända. Om checksummeringen görs av data på disk _efter_ RAM så kan forumscenariot inte inträffa förutom vid hashkollision eller någon bugg.

Av länken jag postade, så säger han att om RAM minnet är trasigt, så kommer ZFS inte att börja skriva sönder data. Mao, du måste inte ha ECC RAM. Din länk säger att om RAM minnet är trasigt så kommer ZFS skriva sönder data - men det stämmer inte (säger min länk).

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av MikaelSwahn:

Av länken jag postade, så säger han att om RAM minnet är trasigt, så kommer ZFS inte att börja skriva sönder data. Mao, du måste inte ha ECC RAM. Din länk säger att om RAM minnet är trasigt så kommer ZFS skriva sönder data - men det stämmer inte (säger min länk).

Du får nog läsa tråden igen från början. Läs sedan igen vad jag skrev i mitt inlägg som du precis citerade.

Citera mig för svar.
Arch Linux

Trädvy Permalänk
Medlem
Registrerad
Aug 2017
Skrivet av Dimman:

Du får nog läsa tråden igen från början. Läs sedan igen vad jag skrev i mitt inlägg som du precis citerade.

Jag förstår inte. Du skriver följande: "2) Vid hypotetiskt förflyttat minnesfel så kan man korrumpera redan korrupt data ännu mer (på disk) med ZFS när någon läser data."

Länken jag postade motsäger detta. Din länk från FreeBSD säger att om RAM minnet är korrupt så kommer ZFS skriva sönder allt data. Därför behövs ECC. Men min länk säger att det är fel. Min länk pekar ut din FreeBSD länk och säger att den är fel.

Trädvy Permalänk
Medlem
Plats
plats
Registrerad
Maj 2006
Skrivet av MikaelSwahn:

Jag förstår inte. Du skriver följande: "2) Vid hypotetiskt förflyttat minnesfel så kan man korrumpera redan korrupt data ännu mer (på disk) med ZFS när någon läser data."

Länken jag postade motsäger detta. Din länk från FreeBSD säger att om RAM minnet är korrupt så kommer ZFS skriva sönder allt data. Därför behövs ECC. Men min länk säger att det är fel. Min länk pekar ut din FreeBSD länk och säger att den är fel.

Ja hans länk är felaktig. Du har rätt.

Nätverksnörd

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av MikaelSwahn:

Jag förstår inte. Du skriver följande: "2) Vid hypotetiskt förflyttat minnesfel så kan man korrumpera redan korrupt data ännu mer (på disk) med ZFS när någon läser data."

Länken jag postade motsäger detta. Din länk från FreeBSD säger att om RAM minnet är korrupt så kommer ZFS skriva sönder allt data. Därför behövs ECC. Men min länk säger att det är fel. Min länk pekar ut din FreeBSD länk och säger att den är fel.

Skrivet av moire:

Ja hans länk är felaktig. Du har rätt.

Ska försöka vara tydlig. Det är inte min länk utan var en länk som någon postade som motargument mot mitt inlägg om att ECC är rekommenderat, inget krav.

Ska vi nu vara helt korrekta så kan vi alla ha fel. Det är fortfarande oklart om det är teoretiskt omöjligt att minnesfel kan orsaka datakorruption mot disk. I artikeln som Mikael länkar så är det även rätt glasklart att det inte är omöjligt med datakorruption, bara extremt osannolikt. Hypotetiskt worstcase?

Har för övrigt inte sagt att ett minnesfel skulle göra att all data skrivs sönder. Snarare att det verkar/verkade finnas en risk (igen, läs ej omöjligt) att _någon_ data skrivs ner ”mer” felaktigt än tidigare.

Om jag får tid att gräva mig in i implementationen nån dag för att se exakt vad som kan/inte kan ske så återkommer jag. Ska vi lämna det där?

Skickades från m.sweclockers.com

Citera mig för svar.
Arch Linux

Trädvy Permalänk
Medlem
Plats
Strängnäs
Registrerad
Aug 2005

Okej, på den gamla goda DDR2 tiden så rasade en av ram minnena i min dåvarande Freenas server...

Det upptäckte jag först när en scrubb började påstå att hela min pool var pepprad av fel.

I memtest så rasslade bara felen, nästan varenda minnesadress gav helt vansinniga nivåer av korruption.

Efter att jag bytt minnet till ett okej så scrubbade freenasen om och jag slapp rota fram backuppen

Om bristen på ECC hade vart livsfarligt some en viss mod på freenas forumena hävdar för ZFS så hade min pool dött..

Min personliga åsikt är att ECC är att rekommendera av samma anledning att man rekommenderar raidz1/2/3 över striped/jbod - Större feltolerans.

Ett annat plus med ECC minnen är att det behövs inte reguljära memtest körningar, single bit flips fixas och rasar minnet så stannar burken och klagar.

Trädvy Permalänk
Medlem
Registrerad
Aug 2007
Skrivet av Johan86c:

Endast 5000 timmar/ 200 dagar kattfilm i råformat, det visar att det ändå inte är så mycket lagring.

Vad räknar du med för upplösning då?

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Karlstad
Registrerad
Nov 2010
Skrivet av Patrik356b:

Vad räknar du med för upplösning då?

Skickades från m.sweclockers.com

4k i råformat enligt den jag citerades uträkning. (jag orkar ej kolla om det)