Experiment med URE

Permalänk

Experiment med URE

För en massa år sedan dömdes RAID 5 som en följd av att sannolikheten att få ett slumpmässigt fel under rebuild av ett degraderat raidset ökade när hårddiskarna blev större.

Jag har länge tyckt att tillverkarnas specar verkat väldigt snålt tilltagna. Sannolikheten för unrecoverable read error (URE) brukar ligga mellan 1/1014 och 1/1015 per läst bit för konsument- och enterprisediskar. Om dessa fel inträffade slumpmässigt och oberoende av varandra skulle det innebära att sannolikheten att läsa N bits utan fel är

(1-felsannolikheten per läst bit)N

Med en URE-frekvens på 1/1014 skulle det innebära att man skulle lyckas läsa 10 TB (80000000000000 bits) felfritt i ≈45% av fallen.
Med en URE-frekvens på 1/1015 ökar sannolikheten till ≈92%.

Jag tror att tillverkarnas tillförlitlighetsspecar mer ska betraktas som ett gränsvärde för bedömning av garantiärenden än ett realistiskt mått på tillförlitligheten hos en normalpresterande hårddiskindivid. Och jag tänkte försöka testa det.

Jag har följande utrustning:

  • 1 gammal arbetsstation

  • 1 kontrollerkort IBM M1015, flashad med firmwarevarianten utan RAID-funktioner.

  • 8 st SAS-diskar från HGST à 4 TB. Diskarna, i ett JBOD-set, har tidigare använts för backup av diverse jox. Under diskarnas livstid har gissningsvis 200 TB lästs från dem utan bekymmer. Innan de togs i drift har diskarna kontrollerats genom att man kört badblocks på dem. Diskar som inte klarat badblocks' tester felfritt på andra försöket har skickats tillbaka till återförsäljaren för byte. (Ja, på andra försöket. Det är ganska vanligt att nya diskar rapporterar några skriv- eller läsfel första gången de utsätts för badblocks. Jag antar att de block på disken som är felaktiga från fabrik därefter reallokeras, för senare körningar av badblocks brukar rapportera disken som felfri.) Enligt tillverkarens spec har diskarna en UER-sannolikhet på 1/1015.

Jag tänkte lägga upp experimentet på följande sätt:

  1. Kör 'badblocks -w /dev/sd*' (pass auf! det här kommandot skriver rappakalja till diskarna! dataförlust will happen!) för att kolla att diskarna inte beckat ihop sedan de användes senast.

  2. Fyll diskarna med slumpdata (dd if=/dev/urandom of=/dev/sd*). Inga partitioner, raidset eller filsystem. Bara en skön mix av ettor och nollor.

  3. Läs de första 100 MB och skapa en checksumma.

  4. Upprepa ovanstående tills diskens hela innehåll är checksummat

  5. Logga resultatet av checksummejämförelsen, totala mängden data som lästs samt antalet checksummekontroller som hittat avvikelser.

Hur går det då? Well, jag håller på med den första körningen av badblocks och har börjat slöjda på ett litet pythonprogram för att göra checksummekontrollerna. Fortsättning följer, och jag tar tacksamt emot eventuella förslag på hur experimentet kan göras mer realistiskt.

Snyggat till formattering.
Permalänk
Medlem

Statistik kräver ganska många tester för att ge meningsfullt resultat. Typ att du kör testet 100 gånger vardera på 100 olika hårddiskar. Enskilda avvikelser säger ju inte så mycket, slumpen får för stor inverkan.

Men visst, jag tror också tillverkarna har en marginal i sina värden. Det är väl "bättre än" som anges.

Permalänk
Skrivet av ronnylov:

Statistik kräver ganska många tester för att ge meningsfullt resultat. Typ att du kör testet 100 gånger vardera på 100 olika hårddiskar.

Ja. Validiteten på tester av åtta diskar av samma modell med likartade serienummer räcker ju inte så långt. Min tanke var att några särskilt djärva sweclockare skulle våga köra stresstestet jag tagit fram på andra modeller av diskar för att därigenom höja validiteten hos resultatet.

Skrivet av ronnylov:

Enskilda avvikelser säger ju inte så mycket, slumpen får för stor inverkan.

Men visst, jag tror också tillverkarna har en marginal i sina värden. Det är väl "bättre än" som anges.

Precis. Jag vill veta hur mycket bättre än spec den faktiska tillförlitligheten är.

Nu har jag kört badblocks på 8 diskar. Jag hade underskattat kylbehovet -- att bara ha diskarna liggande lösa på arbetsbordet i labbet leder till att de blir ca 50°C, så någon form av kylning bör fixas. De är visserligen specade att klara 60°C, men lite marginal kan ju vara bra...
En av diskarna rapporterade 4 trasiga block i följd, så den blev utsatt för en andra omgång badblocks, som också rapporterade 4 trasiga block. Det festliga är att det inte rör sig om samma block. Den disken är nu utbytt mot en annan och en tredje omgång av badblocks är i gång.

Samtidigt som jag körde badblocks på den strulande disken passade jag på att även köra det på övriga diskar. Där har inga fel rapporterats efter sammanlagt 2×7×4=56 TB=4,48×1014 lästa bit.

Permalänk
Medlem

Kylningen kan också påverka resultatet. Jag har haft hårddiskar som genererat fel i min ZFS raid när de gått för varma men då kylningen sedan förbättrats så har de fortsatt fungera felfritt. Men dina övriga diskar verkar felfria ändå trots värmeproblemet så det verkar ju lovande för dem.

Ibland när man testar livslängd så höjer man värmen onormalt mycket för att slippa testa så länge och sedan räknar man om det till livslängd vid normal temperatur. Kan inte så mycket om det själv men en kollega på jobbet försökte förklara det när han höll på med ett forskningsprojekt gällande accelererad livslängdsprovning av komponenter. Man kunde tydligen räkna ut hur länge man skulle behöva testa för att komma upp i en viss förutbestämd statistisk säkerhet i resultatet. Klurigt...

Apropå statistik - man kan ju tänka att man slår en tärning sex gånger och kollar om man får en sexa. Rent statistiskt borde man ju ha fått det om man ser i genomsnitt över tiden och många försök. Men har man tur får man en sexa redan vid första kastet och man kan till och med få sex sexor på sex kast. Har man då en bättre tärning än andra eller hur ska man tolka det? Troligtvis hade nog bara slumpen spelat lite spratt. Men fortsätter man och kastar tärningen 100 gånger så borde man ha fått ungefär 17 stycken sexor. Tvivlar inte på att du förstår detta så du får väl fortsätta ett tag till så får vi se vad du kommer fram till

Permalänk
Medlem

Det är inte enstaka bit fel vid läsning som är problemet utan att disken krashar helt! Då det är en brytal belastning vid en rebuild jmf. den annars genomsnittliga anvädningen av en disk! Det är stor risk att fler diskar krashar vid en rebuild. Pga detta är raid5 dött idag.

Visa signatur

Nätverksnörd

Permalänk
Inaktiv

slöseri på tid

läs på om vad det är du testar så förstår du varför

"testerna" du utför gör riktigt vad du tror..

Permalänk
Skrivet av moire:

Det är inte enstaka bit fel vid läsning som är problemet utan att disken krashar helt!

Jaså? Jaha? Well, det har inte heller hänt. Drygt trettio timmar kontinuerliga läsningar, sammanlagt 120 TB lästa.
Ditt påstående motsägs dessutom av den här rapporten:

Citat:

One of our key findings has been the lack of a consistent pattern of higher failure rates for higher temperature drives or for those drives at higher utilization levels.

(Och av min personliga erfarenhet, som grundar sig på system som vissa veckor skriver flera terabyte per dygn och andra veckor inte jobbar alls. Diskfel är tämligen jämnt utspridda över tiden, oberoende av belastning.)

Det vore härligt med en källa på ditt påstående.

Skrivet av moire:

Då det är en brytal belastning vid en rebuild jmf. den annars genomsnittliga anvädningen av en disk!

I call bullshit. Om diskar skulle krasha av att belastas maximalt skulle väl alla blogginlägg ha varnat för det i stället för det väldigt specifika fallet "rebuild av raidfemma"? Normen för RAIDkort är dessutom att INTE göra rebuild med högsta prioritet.

Permalänk
Skrivet av anon40704:

slöseri på tid

läs på om vad det är du testar så förstår du varför

"testerna" du utför gör riktigt vad du tror..

Utveckla gärna.

Permalänk
Medlem
Skrivet av Hieronymus Bosch:

Jaså? Jaha? Well, det har inte heller hänt. Drygt trettio timmar kontinuerliga läsningar, sammanlagt 120 TB lästa.
Ditt påstående motsägs dessutom av den här rapporten:
(Och av min personliga erfarenhet, som grundar sig på system som vissa veckor skriver flera terabyte per dygn och andra veckor inte jobbar alls. Diskfel är tämligen jämnt utspridda över tiden, oberoende av belastning.)

Det vore härligt med en källa på ditt påstående.
I call bullshit. Om diskar skulle krasha av att belastas maximalt skulle väl alla blogginlägg ha varnat för det i stället för det väldigt specifika fallet "rebuild av raidfemma"? Normen för RAIDkort är dessutom att INTE göra rebuild med högsta prioritet.

Nej den rapporten säger ingenting alls om det, , utan tala om fördelning per år. inte per användarscenario, om något så visar den på att raid5 är riskfullt att använda om du är mån om din data.

Det är skillnad på att skriva samt läsa data på en hel disk under flera dygn än enstaka sektorer här och där.
Mirror används för bästa säkerhet samt även prestanda.
Mirror ger faktsikt större säkerhet än raidz2/6 , trots att man med z2/6 har större teoretisk skydd just pga den större belastning vid resilver/rebuild samt ökad risk för krash av andra diskar från samma batch.

raid5 är generellt inte rekommenderat längre. Diskar från samma batch tenderar att krasha "samtidigt" , se din ref.
Raid5 är inte best practise längre ,så är det bara. Pga stor risk för dataförlust.

http://www.zdnet.com/article/why-raid-6-stops-working-in-2019...
http://en.community.dell.com/techcenter/b/techcenter/archive/...
http://lwn.net/Articles/237924/
http://www.smbitjournal.com/2012/05/when-no-redundancy-is-mor...
http://queue.acm.org/detail.cfm?id=1670144
http://raid6.com.au/posts/RAID5_considered_harmful/

Visa signatur

Nätverksnörd

Permalänk
Skrivet av moire:

Nej den rapporten säger ingenting alls om det, , utan tala om fördelning per år. inte per användarscenario, om något så visar den på att raid5 är riskfullt att använda om du är mån om din data.

OK, jag försöker igen. Sidan tolv:

Citat:

One of our key findings has been the lack of a consistent pattern of higher failure rates for higher temperature drives or for those drives at higher utilization levels.

Skrivet av moire:

Det är skillnad på att skriva samt läsa data på en hel disk under flera dygn än enstaka sektorer här och där.

Så var är varningarna för att läsa data på en hel disk under flera dygn? Varför är det specifikt rebuild av RAID som är så farligt? Varför är inte backup av stora datamängder till disk, till exempel, något problem? Och om rebuild inte tar "flera dygn", är det fortfarande ett problem?

Skrivet av moire:

Mirror används för bästa säkerhet samt även prestanda.

Visst, under ett stort antal variabler har RAID1 mindre risk för dataförlust som en följd av fallerade diskar. Men det är inte riktigt det jag försöker testa. Den större kostnaden för en raidetta bör också tas med i beräkningen - en raidfemma som jag har råd med kommer att skydda mitt data bättre än en raidetta som jag inte kan köpa.

Skrivet av moire:

Diskar från samma batch tenderar att krasha "samtidigt" , se din ref.

Hmm, tar rapporten verkligen upp det? Jag ser en stigande felfrekvens med ålder, men betänk att

Läs gärna mitt första inlägg. De där artiklarna baserar sina beräkningar på hårddisktillverkarnas egna specar på tillförlitlighet. Mitt experiment visar att diskarnas faktiska tillförlitlighet troligtvis är högre än vad specen anger.

Artiklarna motsäger dessutom din hypotes att "Det är inte enstaka bit fel vid läsning som är problemet utan att disken krashar helt!"...

Om sannolikheten för URE verkligen var 1×-15 per läst bit så borde mina diskar, efter att 200 TB (1,6 petabit) lästs, ha drabbats av minst ett URE med ca 86% sannolikhet. Frånvaron av fel kan förklaras på några sätt:

  • Faktiskt URE är högre än tillverkarens spec.

  • Jag har tur! I takt med att testet fortsätter kommer jag att behöva mer och mer tur...

  • Mitt testprogram (eller OSet under det) maskerar fel. Jag har testat att

    • förändra data på disken, varvid skillnaden detekterades av testprogrammet

    • använda en disk som tidigare strulat, varvid läsfelen upptäcktes av OSet och testprogrammet kraschade

    , så dessa typer av fel kan i alla fall detekteras. Det utesluter ju inte att andra typer av fel kan läsas korrekt av OSet, men få en raidkontroller att misslyckas med läsningen eller få raidkontrollern att markera disken som fallerad.

Permalänk
Medlem

1E-15 är normaliserade värden tänkt från större grupper av diskar

Hårddisk ger inte ifrån sig enstaka bitfel i en bitström - den ger ifrån sig 4 till 16 sektorer i rad med bara skräp på en gång vid fel och det inte utan protester och oftast genom att inte ge någon data alls och ge mediafel (IOERR) istället. Vi pratar inte om silent error här.

Det kanske är illa om man inte kan läsa en sektor, men det som är värre är 'silent error' av en sektor korrupt data som kan läsas in omärkligt och cirkulera i olika behandlingar och kan ge fatala konsekvenser många steg senare. Är det läsfel med korrupt data så vill man veta om det, så att man kan ta ställning till problemet när det sker!!! (och det är så RAID:s beslutsprocess arbetar - en disk som inte vill lämna ifrån sig data inom stipulerad tid (pga. för mycket läsfel) - anses som då felaktig data och man använder redudans-datat som den giltiga datat och skriver om de sektorer som strular på den disken som vägrade ge data i tid, och om det inte går - sparka ut disken ur RAID:en )

Skall man få uppgivna värden så handlar det snarare om att läsa 1E15 4-16 sektors från en disk-array där någon av diskarna i arrayen vägrar att ge ifrån sig 4-16 sektorer data någon gång under testet, och då blir det många TB läst innan det inträffar...

(däremot skall man inte anta detta om man tex. läser SD och microSD som mycket väl kan leverera trasiga sektorer utan att det är något som reagerar på det i hårdvaran eller ger IO-error - tyvärr - ni som fått trasiga kamerabilder i SD-minnen köpta i asien/ebay vet vad jag menar )

---

Det saknas en rad på de flesta hårddisk-specar och de flesta media i allmänhet men som börja dyka upp på tex. LTO tapestreamers och det är sannolikheten för _oupptäckta bitfel_ (silent errors) och för TLO7 satt på 1E-27 medans för ej korrekterbara fel är satt på 1E-17 och sannolikheten för korrekterbara fel är nere på 1E-10.

Även för en bandstreamer så kommer det inte 1 bit fel per 1E17 bitar lite slumpmässigt hur som helst utan även här, precis som snurr-HD så när felen kommer så är det en hel bunt sektorer som är helt trasiga på en gång och inget som man missar.

Permalänk
Skrivet av xxargs:

1E-15 är normaliserade värden tänkt från större grupper av diskar

Så kan det vara. Har du sett någon referens till hur de här värdena faktiskt tas fram? Jag gissar att det inte ens är resultatet av accelererat åldrande på stora populationer av diskar längre, utan bara något slags "äh, välj ett lagom litet värde och hantera de garantiärenden som uppstår".

Skrivet av xxargs:

Hårddisk ger inte ifrån sig enstaka bitfel i en bitström - den ger ifrån sig 4 till 16 sektorer i rad med bara skräp på en gång vid fel och det inte utan protester och oftast genom att inte ge någon data alls och ge mediafel (IOERR) istället. Vi pratar inte om silent error här.

Så är det nog. Fel på hårddiskar verkar dessutom vara flockdjur -- om ett fel detekteras så följer ofta fler fel.
Att modellera felsannolikheten som om felen vore ensamma och ungefär jämnt fördelade ger alltså en felaktig bild av hur ofta en serie lyckade läsningar avbryts av en eller flera felaktiga dito.

Permalänk
Medlem

@Hieronymus Bosch: Det stora problemet med raid överhuvudtaget är väl att för många använder det som backup då det egentligen bara är en realtidsgaranti. Precis som sista siffran i ditt personnummer så kan jag se att ditt personnummer är korrekt kalkylerat. Däremot går det inte att se att du är "rätt" person i fråga, även om jag frågar skatteverket och kollar mot ditt namn och adress, då jag måste ha något annat som bekräftar din identitet.

Det en raid "garanterar" är att informationen inte blir korrupt i realtiden. För att garantera information så måste du ändå ha en backup eller två för att säkra informationen. Med andra ord är det väldigt stor chans att då en RAID 1,5 eller 6 havererar så hinner du göra en snygg avstängning av systemet och hinner springa till en datorsäljare för en ny hårddisk.

För privatpersoner är detta oftast den lättaste lösningen. Däremot är det ingen garanti på din data. Om t.ex. ett virus skriver om en fil eller du oavsiktligt raderar den på en RAID 1 så kommer både originalet och "backupen" var ändrad och på en RAID 5 så kommer kontrollsumman fortfarande vara korrekt. Ingen form av raid kan någonsin garantera innehållet på något sätt.

Möjligen skulle ett journalförande filsystem med endast adderande information kunna klassas som säkert då data aldrig skulle ändras, bara läggas till på ny plats. Ungefär som notationen i ett schackspel. Men det är inte helt säkert då det fortfarande kan finnas virus som "offline" skulle kunna ändra informationen genom en bitändring utifrån filsystemet. Även om man hade filsystemet utanför "diskens kapacitet" på ett kretskort så finns fortfarande fel, externa komplikationer och tjuvar som ett problem.

Helt enkelt: Det en raid gör är att garantera att ett paket kommer fram, inte dess innehåll.

Visa signatur

Server: Fractal design Define 7 XL | AMD Ryzen 7 5800X 8/16 | ASUS ROG CROSSHAIR VIII DARK HERO | 64GB Corsair @ 3000MHz | ASUS Radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2TB Samsung 850 PRO SSD | 6x Seagate Ironwolf Pro 10TB
WS: Phantex Entoo Elite | AMD Ryzen Threadripper 1950X 16/32 | ASUS Zenith extreme | 128GB G.Skill @ 2400MHz | ASUS Radeon HD7970 | 3x 2TB Samsung 960PRO M.2 | 6x Seagate Ironwolf Pro 10 TB
NEC PA301W 30" @ 2560x1600 | Linux Mint 21.3 Cinnamon

Permalänk

Jag tittade till diskarna i kväll.
De åtta diskarna med URE-sannolikhet på 10-15 per läst bit har läst drygt en petabyte sedan testet påbörjades.
Två st konsumentdiskar à 4 TB (Seagate, någon modell för NAS-bruk, SATA-anslutning) med en URE-sannolikhet på 10-14 har läst 216 TB.

Ingen av dessa diskar har rapporterat något fel. Om diskarnas verkliga sannolikhet att drabbas av URE var lika stor som den sannolikhet som anges i specen så har jag haft en väldig tur. Sannolikheten att lyckas läsa såpass mycket data utan fel är ungefär 1/5000 för de åtta HGST-diskarna och mindre än en på trettio miljoner för de bägge Seagate-diskarna.

Jag har även mixtrat lite med en skräpdisk (någon gammal Seagate, 500 GB SATA) för att verifiera att mitt testprogram verkligen hittar fel. Det är ganska lätt att provocera fram läsfel genom att knacka lätt med ett skruvmejselskaft på disken, och dessa detekteras av testprogrammet.

Lessons learned:

  • Felsannolikheten hos diskar som överlevt ett inledande test med programmet badblocks är tillförlitligare än vad specen säger.

  • Gör en funktionskontroll på diskar innan de driftsätts.

  • URE är, i de allra flesta fall, inte ett skäl att avstå från att använda RAID 5.

  • Och knacka inte på hårddiskar med skruvmejselskaft om du vill att de ska fungera normalt.

Permalänk
Skrivet av Hieronymus Bosch:
  • Felsannolikheten hos diskar som överlevt ett inledande test med programmet badblocks är tillförlitligare än vad specen säger.

Men DÖH! Vad jag menade var naturligtvis att felsannolikheten är lägre.

Liten och väldigt försenad uppdatering: Delar av hårdvaran jag använde till testet behövdes till ett annat projekt, så försöket avbröts efter någon vecka. Senast jag tittade till diskarna hade de läst nästan 4 PB och ännu inte upptäckt något fel.