Dotaz: RAID5 - 1 chybějící disk, chybná data

[miki.lbc]

Dobrý den, mám soft RAID 5: (mdadm)

cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sda1[0] sdh1[5] sdd1[3] sdc1[2] sdb1[1]
      1845476736 blocks super 1.0 level 5, 32k chunk, algorithm 2 [5/5] [UUUUU]
      bitmap: 0/4 pages [0KB], 65536KB chunk

unused devices: none

Po zcela nepochopitelné chybě: (z logu)

blk_update_request: I/O error, dev sdh, sector 112434432
bře 01 06:32:45 HQ-Server-NAS kernel: sd 8:0:0:0: [sdh] tag#28 CDB: Read(10) 28 00 06 b3 9d 00 00 00 b0 00
bře 01 06:32:45 HQ-Server-NAS kernel: sd 8:0:0:0: [sdh] tag#28 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
bře 01 06:32:45 HQ-Server-NAS kernel: ata9: EH complete
bře 01 06:32:45 HQ-Server-NAS kernel: ata9.00: disabled
bře 01 06:32:45 HQ-Server-NAS kernel: ata9: reset failed, giving up
bře 01 06:31:55 HQ-Server-NAS kernel: ata9: softreset failed (1st FIS failed)
bře 01 06:31:45 HQ-Server-NAS kernel: ata9: hard resetting link
bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: cmd 60/b0:d0:00:9d:b3/00:00:06:00:00/40 tag 26 ncq 90112 in
                                                res 40/00:d0:00:9d:b3/00:00:06:00:00/40 Emask 0x10 (ATA bus error)
bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 06:31:45 HQ-Server-NAS kernel: ata9: SError: { UnrecovData 10B8B BadCRC }
bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: irq_stat 0x08000000, interface fatal error
bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: exception Emask 0x10 SAct 0x4000000 SErr 0x280100 action 0x6 frozen

Následované (z logu)

md/raid:md0: Disk failure on sdh1, disabling device.
md/raid:md0: Operation continuing on 4 devices.

Byly soubory přístupné, ale některé obsahovaly blbosti. Disk jsem připojil na jiný port řadiče a zatím funguje OK (pole je sestavené a po doplnění disku do pole (re-add) jsou soubory v pořádku).

Dal jsem se do pátrání co je špatně, protože RAID 5 by měl poskytovat OK data i za předpokladu výpadku jednoho disku. Na funkčním poli jsem: odpojil pole, ručně nastavil:

mdadm --manage /dev/md0 --fail /dev/sdh1

a pole opět sestavil (s 4-mi z 5-ti disků). Překvapivě data jsou stejně špatně jako předtím. Po zpětném připojení disku (re-add) jsou data zase OK.

Otázka zní: Co dělám špatně, že jsou data poničená, když jeden disk chybí? Je tohle normální chování raid5?

Pro jistotu ještě:

mdadm --examine /dev/sdh1
/dev/sdh1:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x1
     Array UUID : f7090e9b:234dc67a:95fe16d6:99663094
           Name : any:0
  Creation Time : Mon Feb 29 19:55:03 2016
     Raid Level : raid5
   Raid Devices : 5

 Avail Dev Size : 922738408 (440.00 GiB 472.44 GB)
     Array Size : 1845476736 (1759.98 GiB 1889.77 GB)
  Used Dev Size : 922738368 (440.00 GiB 472.44 GB)
   Super Offset : 922738672 sectors
   Unused Space : before=0 sectors, after=288 sectors
          State : clean
    Device UUID : 0a1ca6f6:783ade5e:b7e65361:16059866

Internal Bitmap : -16 sectors from superblock
    Update Time : Tue Mar  1 08:14:57 2016
  Bad Block Log : 512 entries available at offset -8 sectors
       Checksum : d3ae3f40 - correct
         Events : 3974

         Layout : left-symmetric
     Chunk Size : 32K

   Device Role : Active device 4
   Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing)

Děkuji za reakce

---

---

Odpovědi

[alkoholik]

Co se stane, kdyz pustis echo check > /sys/block/md0/md/sync_action ?

[miki.lbc]

Je to divný, dělá kompletní sync

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdc1[2] sdb1[1] sdh1[5] sda1[0] sdd1[3]
      1845476736 blocks super 1.0 level 5, 32k chunk, algorithm 2 [5/5] [UUUUU]
      [>....................]  check =  0.1% (801920/461369184) finish=38.2min speed=200480K/sec
      bitmap: 2/4 pages [8KB], 65536KB chunk

unused devices: none

Myslíte, že to není synchronizovaný? (vypadá to tak)

Jak je to možné? Večer jsem sestavil pole, počkal až se dokončí sync a nahrál data. Pak několikrát pole zastavil a spustil, přidelil práva souborům....

Nechápu proč to není synchronizovaný?

[Jendа]

Až to dojede, přečti si /sys/block/md0/md/mismatch_cnt, asi tam bude nenula. Pak vykopíruj soubory v okamžiku kdy je to správně, pole smaž a vyrob znovu (pokud jsi kaskadér, můžeš zkusit místo check udělat repair).

A podezříval bych vadnou RAM.

[miki.lbc]

Výsledek: 220178200

Děkuju

[miki.lbc]

RAM je OK. Zálohu dat mám. Jdu na nové vytvoření pole.

[Michal]

Tady se ukazuje, proc je lepsi pouzvat FS s kontrolnimi soucty dat jako btrfs nebo zfs.

Podle popisu musel jeden disk dlouhodobe zapisovat poskozena data. Jedine co je divne, ze to mnohem drive nezacalo rvat do logu ze je problem.

[miki.lbc]

BTW: vubec bych se nedivil, kdyby za BadCRC mohl vadny kabel a ne port.

[miki.lbc]

ten jsem vyměnil současně s přepojením na druhý port

[miki.lbc]

Pokračování příběhu

RAM otestována a je OK.

Staré pole zrušeno (včetne mdadm --zero-superblock /dev/sdX1), pro jistotu přeformátované disky na ext4, nastaven typ patrisny na raid, následně pole vytvořeno:

mdadm --create --bitmap=internal --metadata=1.2 --level=5 --chunk=32 --raid-devices=5 /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sdh1

Po dokončení synchnizace: (pole zatím není zformátované) a pokusu o kontrolu

echo check > /sys/block/md0/md/sync_action

cat /sys/block/md0/md/mismatch_cnt

už mám po 11% kontroly 106134272 chyb.

Já už fakt nevím, co dělám špatně! Prosím poraďte

[miki.lbc]

Už asi vím co: z logu:

ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/08:88:70:21:31/04:00:08:00:00/40 tag 17 ncq 528384 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:80:30:1c:31/05:00:08:00:00/40 tag 16 ncq 688128 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:78:f0:16:31/05:00:08:00:00/40 tag 15 ncq 688128 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:70:b0:11:31/05:00:08:00:00/40 tag 14 ncq 688128 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/b8:68:f8:0f:31/01:00:08:00:00/40 tag 13 ncq 225280 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:60:b8:0a:31/05:00:08:00:00/40 tag 12 ncq 688128 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:58:78:05:31/05:00:08:00:00/40 tag 11 ncq 688128 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:50:38:00:31/05:00:08:00:00/40 tag 10 ncq 688128 in
                                                res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error)
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED
bře 01 14:35:58 HQ-Server-NAS kernel: ata9: SError: { UnrecovData 10B8B BadCRC }
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: irq_stat 0x08000008, interface fatal error
bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: exception Emask 0x10 SAct 0x3fc00 SErr 0x280100 action 0x6 frozen

Jdu bádat dále :(

[alkoholik]

Tu RAM jsi otestoval jak?
Zkus balik memtester. Pousti se jako normalni proces v linuxu. Nasel mi i chyby, ktere memtest86+ nepoznal.
Mozna to ma neco spolecneho s turbem nebo tak..

[j]

Na vadny ram by ti padaly aplikace ... zapis na disku je az to posledni, navic v jeho pripade jde pokud vidis o jeden disk, takze je v hajzlu zcela zjevne prave ten.

Jinak je na tom nadherne videt, jak je SW RAID pekne napytel. HW mi reportuje vadnej disk jeste driv, nez se staci podelat, a sync pole sem nedelal za poslednich 10 let snad nikdy, protoze ten disk se dycky stihnul zreplikovat na spare.

[miki.lbc]

Teď už obojím.

memtester 15000 1
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 15000MB (15728640000 bytes)
got  15000MB (15728640000 bytes), trying mlock ...locked.
Loop 1/1:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : ok         
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

Done.

Jdu laborovat disk/řadič

[miki.lbc]

Pokračování II:

Na 4 discích předtím byl RAID0 a vše fungovalo.

Pokud teď udělám na těch samých discích RAID5 (pouze na 4, oproti nahoře z 5) tak to taky úplně stejně nefunguje.

Nové pole > počkání na synchronizaci > check > obrovské množství chyb > repair > check > obrovské množství chyb.

Už si začínám myslet, že buď dělám něco fakt špatně (odebrání disků/pole) nebo to prostě nefunguje.

[...]

Pokud máš v logu hlášky typu http://www.abclinuxu.cz/poradna/linux/show/414117#9, tak se věnuj spíš těm hláškám a ne vytváření nového pole. Něco v hardwaru je špatně.

[miki.lbc]

Proto to sestavuji teď pouze z původních 4 disků.

Žádný hlášky (tyhle o selhání ata) už v logu nejsou.

Bohužel je to stále stejné :(

[miki.lbc]

Pokračování III

Pole (4 disky viz výše) bylo přeneseno na jiný HW.

Už jsem neměl sílu znovu pole vytvářet takže:

"repair" >> --stop >> --assemble >> check

Bohužel identické chování, nalezeno velké množství chyb. V logu nic.

Už mě fakt jedině napadá, že by ty disky byly špatný, ale jak jsem psal výše, tak z toho ještě v pátek běžel RAID0 bez jediného problému (takže se mi to úplně nezná)

:( (jdu spát)

[ES]

Proc by nemohly bejt spatny? hdd klidne odejde za 0,5s kopanec, nebo za 1s utrhne se hlava, nebo za par hodin nez se "roztahaj vadny sektory" na casti s datama........ nebo .....

[...]

Před třemi týdny mi odešel disk v NAS serveru. Ráno fungoval úplně bez problémů a odpoledne bylo po něm. Bez varování. Pravidelně kontrolovaný. Předtím, než se odporoučel - žádné vadné sektory, žádné hlášky v logu, prostě vůbec nic. Teď jenom chrčí (resp. by chrčel, protože leží v almaře).

[R]

Nedavno som vypinal jeden "server" (s desktopovymi diskami) kvoli udrzbe. Po zapnuti uz jeden disk (WD) nefungoval - po rozobrati som zistil, ze sa nejako nevydarilo parkovanie mimo platni - odtrhli sa pri tom obe hlavy...

[fish]

Ten novy raid5 tedy chybuje i tam, kde puvodne byl funkcni raid0, nebo jen na jinem HW? Disky jsou stejne? Pred casem jsem narazil na situaci, kdy dochazelo k chybam komunikace s diskem, pri kombinaci disku ruznych vyrobcu na urcitem radici. Pritom SMART ukazoval vse vporadku.

Resenim bylo az vynuceni vypnuti NCQ (libata.force=noncq jako parametr jadra). Konkretne to byl WD Red, ktery ma (udajne) NCQ optimalizovane nejak, aby idealne fungoval spolu se shodnymi disky. V ostatnich pripadech se choval jinak nez ocekaval radic a dochazelo k problemum. Vypnuti NCQ se samozrejme podepise na random access pristupech k disku, ale nebylo to nic tragickeho (presna cisla uz bohuzel nemam).

[miki.lbc]

Bohužel vypnutí NCQ nepomohlo, ale díky. (napíšu za chvíli NE-řešení)

[miki.lbc]

Finální (skoro) konec:

Tak nakonec jsme přišli na zlepšovák: (zrychlení testů)

- Na každém disku udělat 3 partišny (malé, třeba 20G), udělat na každém disku RAID 5 (tedy celkem 5 jedno-diskových polí) což brutálně zrychlilo testy a zjednodušilo přenositelnost

- provést sestavení a kontrolu každého disku/pole ... 4 NOK, 1 OK .. mixování OK/NOK bylo vždy NOK - zajímevé je, že počet chyb při kontrole se měnil/nebo byl konstantní v závislosti na portu řadiče (na to jsme nepřišli proč)

- jeden disk jsme otestovali na zcela jiném HW (staré pomalé AMD s CentOS 7) ... kde také vykazoval chyby

- ve středu jsem rezignoval na RAID5 a sestavil původní RAID0 s původními disky (protože jsem nevěřil že umřely), a v noci nahrál data...

- ráno po půl hodině používání - read only ...

- test 1 disk a 3 partišny v RAID5 byl proveden ještě na "točivém disku" a tam to fungovalo

- takže je to jasné, ty disky jsou skutečně v pr...., kupodivu ne na "opotřebení SSD", opravdu se tváří jako OK (i podle smart short/long) ... teď to řešíme s OCZ co s tím

- každopádně teď to všechno běží na jednom obyčeným starým 2G disku, protože už to bez dat opravdu nešlo (jako nouzové řešení)

Moc děkuju všem za podporu! (obzvláště těm co měli pravdu a říkali že ty disky chcíply)

[k3dAR]

nevim jestli 2G disk neni preci jen uz moc starej na produkcni nasazeni ;)

[miki.lbc]

Je. Ještě je to Barracuda LP (5900 ot.) z roku 2010, ale na "teď hned je absolutně nutný aby to fungovalo" (čti 6h+ budeme kopírovat data) to bylo jediný řešení, musí to pár dní vydržet :-|

[k3dAR]

to je divne, ja 2GB Seagate kupoval nekdy v roce 2000 ;)

[R]

To si mal hned do prveho prispevku napisat, ze je to nejaka SSD sracka a nie normalny disk.

[panCHrz]

+1

[Andrej]

Jediný smysluplný zlepšovák je mkfs.btrfs. To ostatní mi přijde jako zoufalá ztráta času.

[ewew]

Funguje to aj bez ECC pamäte ?

[lertimir]

Navic consumer grade SSD disky použít na RAID je spolehlivě zabije. Podle mne když OCZ zjistí že na tom byl RAID a ne normální FS s kontinuálními soubory, tak vám je hodí na hlavu. Před 2,5 lety tady byl dotaz, kdy tazateli také chcípalo RAID pole s consumer grade SSD. Stačí si přečíst nějaký článek o tom jak jsou SSD chipy organizované, aby člověk věděl, že si musí strašně dát pozor na elektroniku co SSD řídí, protože vlastnosti NAND čipů jsou pro běžné diskové operace strašné, a elektronika to musí oflikovat a obejít.

Největší hrůza, která je možná poslat do SSD je náhodný zápis velkého množství malých bloků. A přesně tohle RAID dělá. Na to aby se SSD s takovou zátěží vyrovnalo, je třeba velmi sofistikované elektroniky a dostatečnou redundanci v paměťových buňkách a to právě mají disky v Enterprise grade. A není divu, že jsou 5x a více dražší na kapacitu. Kvalita disku je v podstatě dána 2 věcmi, kvalitou chipů (rychlost zápisu, rychlost mazací operace, úrovní paralelizace, a kvalitou raditě a sofistikovanosti jeho algoritmů. 128GB flaska do USB a levný 128GB disk na SATA jsou skoro stejně drahé. V té flasce není nic, (možná u některých trochu optimalizace na FAT oblast, která se častěji přepisuje), to SSD používá stejné levné chipy s nízkou odolností a navíc má pár vychytávek, optimalizovaných na to, aby při běžném provozu Windowsí uživatel fungoval dobře.

[Jendа]

A přesně tohle RAID dělá.

O nic víc než ne-RAID použití. Uveď příklad (nejlépe i pro RAID1).

[lertimir]

Máš pravdu spíše jsem měl napsat tazatelův RAID. Protože RAID 1 rozklad po discích samozřejmě nedělá. Ale tazatel měl RAID 5 na 5 discích a tím sníží velikost zapisované struktury do jednoho disku 4x.

Zkus si představit, co bys musel jako programátor dělat, když máš strukturu, kde je Read block 512 B, write block 16 kB a delete block 512 kB. S tím, že číst můžeš jak chceš. Zapsat ten 16 kB block můžeš jen do prázdného místa, Takže když z toho 16kB místa bloku obsadíš jen 512B nebo 1kB nemůžeš zapsat další 1kB do toho samého, musíš přečíst 1kB bloku, co je a zapsat 16kB (s obsazenými 2kB) jinam. A když potřebuješ někam zapsat a nemáš kam, tak jediné, co můžeš je smazat 512kB blok (a mimochodem to smazání trvá neco mezi 100-150 ms což je strašně dlouho). A celé se to má logicky tvářit jako blokové zařízení o velikosti bloku 512B s tím, s žádným rozlílem s prací s bloky. A teď jde o to kolik elektroniky nasázíš okolo, aby jsi přístup k chipům zparalelizoval (jinak máš rychlost jak na pomalých kartách) kolik a jak velkých máš buffery aby jsi jednak zápis odchytil ve vyšší rychlosti než píšeš do chipů, a když už má paralelizaci takovou, že bys zápis stihl tak buffery na to aby jsi požadavky združil a skutečně zapisoval po jednotlivých write blocích. A dále elektroniku, aby jsi byl schopen bloky uklízet, tedy u těch mazací bloky, které jsou z části už namarkované jako volné/neobsazené přečíst zbylá data, zapsat jinam a celý blok smazat. USB flasky to velmi často nedělají samy od sebe vůbec a consumer disky mnohdy potřebují nějakou dobu "nečinnosti", aby se pustily do úklidu, enterprise uklízí i při zátěži.

Osobně si myslím, že je problém, že disky nemají ani option, kdy by hlásily skutečné své parametry (velikosti jednotlivých bloků a ke každému mazacímu bloku jeho vnitřní podstrukturu v write blocích a obsazenost) a řízení takové nestejnoměrné blokové struktury by mělo být součásti FS. Podobně jako tady Andrej opakovaně píše, že RAID by měl být součástí FS jako má ZFS a BTRFS, protože volby jak vytvářet redundanci by měly být se znalostí dat, které se rozprostírají, si myslím, že organizace, co zapisovat do jakých mazacích bloků by mělo být součástí FS. Ano znamenalo by to návrh zcela nového FS a asi dost výzkumu. Ale také si myslím, že dokud Microsoft, neřekne chceme vyvinout zcela nový FS pro SSD disky, pošlete ven informace, co se skutečně v disku děje, nic se nezmění.

[Mti.]

Porad tu ale hanobis raid a nezohlednujes zatez, ktera je nad tim raidem. Pokud se budes bavit o vztekle databazi, ktera bude porad nekde chaoticky menit pokud mozno vsechno, tak ten raid uz nic "navic" neznamena a dokonce tem diskum obcas odlehci! (protoze u raid5 pro male bloky dat k zapisu nebude potreba zapisovat na vsechny, u 1 disku by to odskkal vzdy jen ten samy)

Pokud vim, tak sw raid v jadre uz umi predavat pristup k trimu a v okamziku, kdy teda budes delat spis datovy sklad (pridavat velke soubory a ty se pak budou hlavne cist), budes zapisovat castej do prazdneho mista nez prepisovat existujici obsah. A pro zapsani bunky se nemusi smazat cely blok, pokud zrovna menena cast je volna. (crc bloky se prepisovat budou, to ano)

Ony ty "advanced format" disky uz taky nejsou 512B/512B, ale zapisuje se cela stopa ...

Nicmene tady se porad ohanis necim o raidu a podobne, nicmene cely puvodni prispevek je hlavne o tom, ze disky, misto toho aby slusne selhaly a SPRAVNE zahlasily chyby, tak tise rozbiji data. A to by delat nemely. To, jestli to odejde za pul roku nebo za 10 je v tomto okamziku jedno.

[lertimir]

Já nehanobím RAID. Já jen říkám, že pracujeme v reálném světě s reálnými nedokonalými zařízeními (A mnohdy nedokonalými záměrně, protože výrobce v rámci ušetření něco zanedbal a oflikoval, protože v rámci jeho modelu použití se to zanedbání neprojeví či projeví jen málo.) a je potřeba si tu nedokonalost nebo oflikovanost uvědomovat, podle toho se zachovat.

Můj osobní zážitek s nevhodně použitého zařízení je trochu podobný. Před několika lety jsem si vytvářel domácí server a tehdy jsem měl ideu, že bych měl systém na USB flash a rotační disky na data s RAID 5, které by se uspávaly. Výsledek byl, že nejdříve klesal výkon, rychlost zápisu do USB flash při provádění aktualizace systému byla asi 400-600kB/s (evidentně došly smazané bloky a flaska mazala mazací bloky, když potřebovala něco zapsat) později se systém začal rozpadat a flaska hlásila chyby, nečitelné sektory a vypadala na vyhození. Server jsem pořešil jinak a flash jsem zpětně přeformátovat na FAT32. I když ji už nevěřím, tak ji používám pořád jako druhé přenosné medium a od té doby funguje správně. Všechny sektory jsou čitelné, zapsal (a smazal) jsem už do ní v tomto režimu asi 50x násobek její kapacity a nevykazuje chyby. Potkal jsem i jiné podobné případy.

S tím, že základ problému je v tom, že disky nehlásí, co mají, samozřejmě souhlasím. A OCZ Vectory by měly být slušnější disky. Ale prostě pořád je tu rozdíl mezi Vector a serverovými SSD jako Intrepid a rozdíl mezi cenou u stejně kapacitního disku Vector a Intrepid není jen o maržích, ale také hodně o řídící elektronice. Vzhledem k tomu, že pro oba se vyrábějí NAND MLC chipy stejnou 19nm technologií, tak v těch chipech moc rozdílů, kromě pečlivého testování a výběru nebude.

[miki.lbc]

Zátěž byla především rychlé čtení malých souborů. A řekněme zápis asi 2000-3000 souborů denně (malých, odhad). Rozhodně za těch 3/4 roku co tam byl RAID 0, to zapsali míň LBA než kolik jsem "přepsal" testy co je špatně (během pár dní).

[miki.lbc]

OCZ o RAIDu ví a poslal jsem jim i SMART (kde je vidět čtení/zápis LBA), takže uvidíme :)

[R]

Citanie a zapis velkeho mnozstva malych blokov je asi jediny dovod, preco by mal clovek pouzivat SSD. Inak staci obycajny disk, ktory mozes aj tisickrat cely prepisat a nic sa mu nestane.

[lertimir]

Jasně a je třeba vzít na paměť, že ty SSD jsou spotřební zboží, a budou při velkém zatížení zápisem odcházet.

[vandrovnik]

Myslím, že kdyby někomu zamítli reklamaci proto, že si dovolil disk použít v RAID 5, dost by se tím znemožnili.

[Petr Šobáň]

A proč by se tím znemožnily, záruka se nevztahuje na normální opotřebení a to že buňku opotřebovals množstvím zápisů není na záruku.

Samozřejmě to že SSD nehlásí chyby když je vyčerpán počet zápisů je špatně....

[miki.lbc]

Kde všichni berete, že to něco nehlásí?

Jen je divný, že jsou všude 000: (value/treshold)

Reallocated_Sector_Ct 0x0000 000 000 000

smartctl 6.2 2013-11-07 r3856 [x86_64-linux-4.1.15-8-default] (SUSE RPM)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     OCZ-VECTOR180
Serial Number:    XXXXXXXXXXXXXXXXXX
LU WWN Device Id: 5 e83a97 100050c8b
Firmware Version: 1.01
User Capacity:    480 103 981 056 bytes [480 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Thu Mar  3 10:37:57 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x1d) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Abort Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        No Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x00) Error logging NOT supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   0) minutes.
Extended self-test routine
recommended polling time:        (   0) minutes.

SMART Attributes Data Structure revision number: 18
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0000   000   000   000    Old_age   Offline      -       0
  9 Power_On_Hours          0x0000   100   100   000    Old_age   Offline      -       4733
 12 Power_Cycle_Count       0x0000   100   100   000    Old_age   Offline      -       78
171 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       162138448
174 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       5
190 Airflow_Temperature_Cel 0x0000   100   100   000    Old_age   Offline      -       24
195 Hardware_ECC_Recovered  0x0000   100   100   000    Old_age   Offline      -       0
196 Reallocated_Event_Count 0x0000   100   100   000    Old_age   Offline      -       0
197 Current_Pending_Sector  0x0000   100   100   000    Old_age   Offline      -       0
208 Unknown_SSD_Attribute   0x0000   100   100   000    Old_age   Offline      -       3
210 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       0
224 Unknown_SSD_Attribute   0x0000   100   100   000    Old_age   Offline      -       1
225 Unknown_SSD_Attribute   0x0000   100   100   000    Old_age   Offline      -       0
226 Unknown_SSD_Attribute   0x0000   100   100   000    Old_age   Offline      -       0
233 Media_Wearout_Indicator 0x0000   100   100   000    Old_age   Offline      -       100
241 Total_LBAs_Written      0x0000   100   100   000    Old_age   Offline      -       1212
242 Total_LBAs_Read         0x0000   100   100   000    Old_age   Offline      -       8024
249 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       42098548

SMART Error Log Version: 1
No Errors Logged

Warning! SMART Self-Test Log Structure error: invalid SMART checksum.
SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


Selective Self-tests/Logging not supported

[Mti.]

Kdyz neumim precist/zapsat sektor, zahlasim chybu primo systemu, ktery se na sektor zrovna ptal, aby ten mohl reagovat. Ne ze si ho vymyslim. Takze u mne je dany kus/serie zmetek (slabe nebo zadne crc?). Pokud ovsem neni zrada v necem jinem. (kable, radic...)

Zrovna smart si kazdy vyrobce hlasi jak mu napadne V jedne masine mi bezi 64GB Transcend (jeste IDE)... a ten priznava asi 5 hodnot. ... a trim taky neumi. Zatim zije.

[vandrovnik]

Přeci musí být jedno, jestli výrobcem deklarovaný počet zápisů během záruky udělá přímo nějaký souborový systém, nebo RAID, nebo třeba uživatel z dlouhé chvíle pomocí dd.

[Petr Šobáň]

Ano to je jedno ale takový disk nevyreklamuješ prostě je to běžné opotřebení a je jedno jak jsi si ho udělal. (Jestli dd nebo raidem.)

[j]

Na hlavu to urcite nehodi, protoze vadnej disk je vadnej disk. Realita je takova, ze v pripade tzv "enterprice" disku si platis predevsim support (kterej stejne stoji za kulovy). Uvnitr je klidne presne totez, jen s trochu jinym firmwarem, kterej je modifikovanej kvuli lepsimu vykonu v poli, ale dyl to nevydrzi.

Raid ma blok tak velkej, jak mu ho nastavis, a zapisuje podle toho, co na nem bezi za aplikaci.

[Andrej]

Co dělám špatně, že jsou data poničená, když jeden disk chybí?

Všechno špatně. RAID funguje jedině tehdy, ví-li o něm filesystém a je-li integrovaný do filesystému. Tedy Btrfs nebo ZFS dávají smysl jako RAID. Ten RAID, o kterém filesystém neví, je náchylný k silent data corruption, což je přesně tato situace.

Problém je, že softwarový (ba i hardwarový, to je úplně jedno) RAID 5, který není integrovaný ve filesystému, splní svůj účel jedině tehdy, pokud disky selhávají stylem všechno nebo nic. Předpokládá se tedy, že disk buď vrací 100% správná data a nedělá nikde chyby, nebo okamžitě a úplně selže, aniž by kdy vrátil špatná data. Takový předpoklad je od praxe na hony vzdálený.

Kdyby tam byl Btrfs RAID 5 nebo ZFS RAIDZ, tohle by se nikdy nestalo díky automatickým checksumům, které filesystém používá. Pro příklad uvažme, jak se z RAIDu 5 čte. Máme-li pole s N disky, pak k přečtení dat stačí 4 disky a na pátém je paritní součet (ať už xor nebo něco sofistikovanějšího). Parita je distribuovaná, tedy každý RAID blok má paritní součet na jiném z disků, aby v RAIDu nebyl jeden přetížený paritní disk. Když je třeba přečíst data, stačí k tomu pouze N - 1 z N disků. Nikdo při čtení automaticky nekontroluje paritu na tom N-tém disku, jestli opravdu sedí — kvůli efektivitě, samozřejmě. Mnohem dalekosáhlejší důsledky z hlediska efektivity má v tomto směru třeba prokládané čtení z několika disků u RAID 1. Ale to už odbočuju. U RAID 5 s N disky je zkrátka potřeba N - 1 operací k přečtení toho, co se zapisovalo N operacemi.

U hardwarového nebo softwarového RAIDu 5 bez podpory ve filesystému se v případě poškození dat na discích přečtou a vrátí špatná data a nikdo problém neodhalí. Selže-li následně jeden z disků, teprve tehdy se při čtení použije parita. Byla-li původní data špatná, rekonstrukce pomocí parity vrátí zase špatná data, ať už je parita samotná zachovaná správně nebo špatně. Není proti tomu žádná účinná prevence!

RAID 1 bez podpory ve filesystému má tentýž problém. Při prokládaném čtení nezjišťuje, jestli se repliky shodují, a i kdyby se neshodovaly, bez checksumů nemá absolutně žádnou možnost zjistit, která z replik mluví pravdu.

RAID 5 v Btrfs nebo RAIDZ v ZFS naopak tohle všechno ustojí bez problémů. Dejme tomu, že při čtení z pole u jednoho disku nesedí checksum pro nějaký stripe. Pak filesystém zaprvé hned ví, na kterém disku jsou pro daný RAID blok špatná data, a zadruhé ví, že musí mimořádně pro tento blok přečíst také paritu (samozřejmě rovněž chráněnou checksumem!) a dopočíst správná data z parity a z N - 2 ostatních zdravých stripů. Navíc je namístě rovnou opravit stripe na tom disku, kde neseděl checksum, aby se pro celý RAID blok zase obnovila plná redundance.

Pro RAID 1 v Btrfs nebo ZFS platí totéž. Čte se prokládaně jako všude jinde a dokud checksumy sedí, je to v pořádku. Jakmile checksum nesedí, načte se daný blok z jiné repliky — z takové, kde checksum sedí — a následně se obnoví pořádek. Opět přímo filesystém ví, která replika selhává a odkud je možné ji obnovit.

Je tohle normální chování raid5?

Ano, je. RAID 5 bez podpory ve filesystému nedává smysl. Je náchylný přesně k těmto chybám, zejména když je na něm navíc ještě nějaký filesystém z minulého desetiletí, který nejen neumí RAID, ale dokonce zjevně ani nedělá checksumy dat. (Hrůza pomyslet!)

Postupem doby pravděpodobnost okamžitého totálního selhání celého disku klesá, zatímco pravděpodobnost silent data corruption roste. To druhé má taky souvislost s rostoucí kapacitou disků. RAID 5 bez podpory ve filesystému nechrání data před poškozením. Některá fakta se člověk naučí the hard way — tak už to v životě chodí.

<off_topic>

Už se těším, až mi jednou zase některý slavný místní žvanil bude tvrdit, že silent data corruption v praxi neexistuje a že disky selhávají jedině jako celek. Skvělou odpovědí pak bude odkaz na tento dotaz. (Ne že by se na webu neválelo hned několik barvitých popisů dalších podobných incidentů.)

</off_topic>

[ewew]

Tu je skôr problém, že SSD nižšiej kvality nie je vhodný.

[miki.lbc]

Moc díky, za dlouhou reakci.

COŽE? WTF? Tak to jsem žil v nějakým vlastním bludu, že je to samo spásný.

Nicméně to nevyvrací, že ty disky jsou v prd...., protože opravená data podle "špatných dat" se nově jeví jako dobrá a tedy kontrola musí vyjít znovu ok.

Na Btrfs a RAIDZ se podívívám.

Je už Btrfs v použitelném stavu? Používáte to někdo?

[Jendа]

Je už Btrfs v použitelném stavu?

Není. Jsou tam podivné bugy a nedotaženosti. Např.

• Mountnutí středně velkého (6TB) svazku trvá minutu.
• Při čtení to vyhlásilo I/O error, ale v dmesg nic. Scrub taky nic neřekl.
• Zdá se, že to furt autodefraguje, i když je vypnutý autodefrag. Prostě to *furt* hrabe na disk. Dokumentace mlčí.
• Má to implementovanou kompresi, ale nikdo neimplementoval dekompresi. Je o tom malinká poznámka v dokumentaci, které jsem si nevšiml.

[Heron]

Mountnutí středně velkého (6TB) svazku trvá minutu.

Vzpomínám na dobu, kdy boot nějakého serveru trval 40 minut a všichni si to považovali, protože to byla známka opravdu velkého serveru. Potom jsem testoval nějaký fs (už nevím, to bylo v době, kdy i ext3 byla těžká novinka) a velký disk se poznal tak, že ho to připojovalo 5 minut. Dneska je to bug

Jinak mě se btrfs 10TB připojuje (připojuju jednak root subvolume a potom několik (asi 8) subvolume a celé to trvá asi jen 20s. A to asi zejména proto, že to systemd připojuje všechno naráz, takže to trochu víc seekuje, než by bylo zdrávo. To tam je několik tisíc snapshotů a několik miliónů souborů (nepočítaje ty v těch snapech).

Zdá se, že to furt autodefraguje, i když je vypnutý autodefrag. Prostě to *furt* hrabe na disk.

I kdyby, tak na tom je špatně co (teda kromě toho, že by to nerespektovalo nastavení)?

Má to implementovanou kompresi, ale nikdo neimplementoval dekompresi. Je o tom malinká poznámka v dokumentaci, které jsem si nevšiml.

To jako že když data jednou zakomprimuješ, tak jsi o ně přišel? Nezdá se. Prosím o odkaz.

[Jendа]

I kdyby, tak na tom je špatně co (teda kromě toho, že by to nerespektovalo nastavení)?

Že mám pod tím pole (ano, nepoužívám to vestavěné v btrfs, protože když jsem ten stroj instaloval, byl integrovaný RAID5 poněkud experimentální), a když se rebuilduje, nebo se kontroluje konzistence, tak to pro samé seekování jede strašně pomalu.

To jako že když data jednou zakomprimuješ, tak jsi o ně přišel? Nezdá se. Prosím o odkaz.

Ne, že balance/defrag umí zkonvertovat existující svazek jako kdyby byl od začátku připojený s volbou compress, ale naopak to neumí. (nic kritického, spíš to ukazuje nedoladěnost)

[Heron]

Ne, že balance/defrag umí zkonvertovat existující svazek jako kdyby byl od začátku připojený s volbou compress, ale naopak to neumí. (nic kritického, spíš to ukazuje nedoladěnost)

Na to by mělo stačit ten svazek připojit jako nocompress a pustit na to balance. Nebo jsem něco přehlíd?

[Jendа]

Ne, balance nemění obsah bloků, jen je znovu rozprskne po disku.

[Heron]

A vida. Tak v tom případě potom pomůže už jen překopírování těch dat. Nebo si počkat na vylepšení nástrojů.

[j]

Mount R5 4x6TB luks ... cca 10s vcetne desifrovani tech disku. Kdyz to nic nedela, tak to nic nedela (disky stojej) ... netvrdim ze je to dokonalost sama, ale pouzivat se to da.

BTW: Na HW kterej muze byt bez varovani odpojen od elektriny pouzivam ext2. Ext3/4 se spolehlive podela.

[R]

Ked niekto namiesto disku pouzije nahodny generator (ako inak sa da nazvat "SSD", co bez problemov vrati uplne ine data, ako tam boli zapisane?), tak potom naozaj potrebuje checksumy.

Klasicke filesystemy a mdraid su postavene na predpoklade, ze v pripade chyby citania disk skutocne vrati chybu.

[Ovrscout]

hmm, já žiji v domění že na disku(HDD i SDD) jsou data ukládaná po sektorech, a v sektoru že je kromě dat také uloženo CRC nebo něco podobného. Takže disk by při chybě čtení neměl vrátit poškozená data ale chybu. Toto se třeba projevuje tím že pokud jsou data na disku poškozená, tak čtení trvá mnohem déle (na klasických desktop HDD) protože se disk snaží číst opakovaně. Možná to není tak spolehlivé jak jsem si myslel a nebo se to už to u moderních disků nepoužívá? Nebo toto platí pouze pro ne-RAID konfigurace?

Nechci tím říci že nemáte pravdu, nebo že je btfrs/zfs zbytečné. Jen mám zafixováno že tam nějaké to zajištění je.

[Jendа]

Už se těším, až mi jednou zase některý slavný místní žvanil bude tvrdit, že silent data corruption v praxi neexistuje

Jak víš, že v tomto dotazu jde o silent data corruption?

[R]

Pri cinskych USB flash diskoch za 5 centov tento jav existuje a obavam sa, ze sa rozsiril do SSD podobnej kvality...

[miki.lbc]

No, tohle byli sice MLC, ale zase bych to jako (úplnej) shit nenazýval. Byli to OCZ Vector 180 (řekněme vyšší řada)

[Hoho]

Pravda OCZ shit není. Je to totiž něco mnohem, ale mnohem horšiho.

[R]

Zjavne to nie je dost vysoka rada na to, aby firmware korektne hlasil chyby citania. Ani dvere by som si tym nepodoprel (klasicky disk je na to lepsi kvoli hmotnosti :)

[Hoho]

Ty vole Andrej tys pravý prorok a otvírač očí. Kurva jak jen mohla a může drtivá většina lidí používat obyčejné filesystémy 30+ let? Těch zkrachovalých firem a sebevražd za kolik můžou ty STRAŠNĚ nespolehlivé disky a filesystémy. Pohroma. Fuj běžným FS! BTRFS na každý disk! Make checksum not war!

[R]

Lebo nikdy v minulosti sa nerobili take srackove disky ako dnesne SSD od pochybnych firiem.

[pavele]

Make btrfs, Not War: The btrfs Revolution, an Unfettered History - Výsledky hledání v Google Books

[miki.lbc]

Hele má pravdu. Otevřel mi oči. Já měl za to že RAID "prostě udělá, že se to neposere" a jsem rád, že jsem na to přišel teď (kdy byla záloha před RAID 0>5) než někdy pak (kde mám sice týdenní, deni a hodinovou přes rsync na jiný stroj, ale kdo má hledat co už je/není mrtvý) Teď to fakt studuju a asi to dopadne tak, že ZFS. Teď řeším jestli OpenNAS nebo se to snažit dostat do OpenSuse. Každopádně Btrfs si asi dám na test na notebook, abych mohl dělat psi kusy.

[fish]

[offtopic] Co si budeme povidat, i pri odhlednuti od tech nestandardnich stavu na ktery jsi narazil, provozovat RAID0 s pocitem "RAID udela, ze se to neposere", neni krok dobrym smerem ;) [offtopic]

[Mti.]

predpokladam, ze na to mel ten raid5

[miki.lbc]

RAID 0 tam byl na "ukaž rychlost" a zůstal tam 3//4 roku. Teď jsem to chtěl pro klid předělat na RAID 5. A bylo to za 1 vteřinu 12h.

[pavlix]

Jenže dobrým směrem nebude ani stejným způsobem provozovat ZFS.

[alkoholik]

Kdyz on je to spis jenom AID0.