Problém se SMR disky Seagate Archive 8TB

[Jan Kasprzak]

FWIW, zprava o stavu k drive diskutovanemu problemu Seagate Archive 8 TB:

- upravili jsme zalohovaci system tak, ze na kazdy disk 3 hodiny zalohuje
a 3 hodiny je v klidu. Pro snazsi vyhodnoceni tohoto stavu ze strany
firmwaru disku jsme jeste behem zalohovani pustili programek, ktery vyrobi
na disku kazdou minutu nejaky maly soubor, ulozi, a pak ho zase smaze.
Aby disk nemel nahodou pocit, ze ted se zrovna nezalohuje.

- tahle uprava trochu pomohla. Zvysili jsme interval na 6 hodin idle
a 6 hodin prace. Od te doby uz asi 6 tydnu nedoslo v jednom ze serveru
k zadnemu vypadku disku tohoto typu. Ve druhem bohuzel ano, az asi po
4 tydnech, pricemz vypadek zrejme koreluje s o neco vetsim mnozstvim
zalohovanych dat v tu dobu. Taky je jeste rozdil v tom, ze jeden zalohovaci
server ma XFS nad diskovou partition, zatimco druhy ma
XFS -> LUKS/dmcrypt -> diskovou partition.

- K poslednimu vypadku doslo temer ke konci toho sestihodinoveho intervalu
aktivity. Mozna to teda opravdu souvisi s interni reorganizaci SMR disku
a tim, kolim dat se v jedne "davce" zapise.

- novejsi jadro (RPM binarka vanilla kernelu z elrepo) zpusobilo, ze zrejme
vypadek disku neni az tak fatalni - po vytazeni disku a vlozeni jineho
prislusny port normalne funguje, neni treba vypinat cely pocitac.

Takze: castecne problem umime obejit, castecne nikoliv, pricinu ale nezname.

-Y.
	
Jan Kasprzak wrote:
: Dan Smolik wrote:
: : opravdu zajímavé a zkoušeli jste vypnout zapnout ten disk ? Mě
: : připadá, že to bude on.
: 
: Vždyť píšu že vyndat disk a vrátit zpět nepomohlo. Dokonce ani vyndat
: disk a dat tam jiny nepomohlo - ten port je zrejme v nejakem divnem stavu.
: 
: Adam Pribyl wrote:
: : Zadny zazrak bych necekal, ale co hlasi smartctl? Nebezi v tu dobu
: : trema self test?
: 
: 	Pravidelne self-testy na techto strojich nepoustime.
: Ve smartctl -a neni nic podezreleho. Jen jsem si vsimnul, ze obcas
: smartctl vypise jen prvni cast vypisu (pokud si dobre pamatuju, tak
: pred "START OF READ SMART DATA SECTION"), pak se vterinu dve nic nedeje,
: a pak teprve se vypise zbytek.
: 
: : Nejaky novejsi FW k tomu treba nevydali?
: 
: 	Na tohle jsem se samozrejme uz dival. Ne, nevydali.
: 
: 	Jeste je zajimavy prubeh toho vypadku. Sklada se to ze dvou fazi:
: nejdriv kernel napise, ze "task jbd/... blocked for more than 120 seconds",
: v iostatu je videt 0 KB read/s i write/s, ale avgqu-sz je nenulove
: a %util je pochopitelne 100.0.
: 
: 	Po dalsich presne 118 minutach (= 2 hodiny minus tech 120
: sekund vyse) teprve prijdou ty SCSI chyby a disk se odpoji. Behem tech
: dvou hodin jeste /dev/sdN existuje, ale pristup k nemu se zablokuje.
: Zkousel jsem treba "echo 1 > /sys/class/block/sdN/device/delete",
: "smartctl -a" a dalsi. Vsechny tyto zablokovane procesy se odblokuji
: po uplynuti tech dvou hodin, kdy jadro zrusi to cele zarizeni.
: 
: -Y.
: 
: -- 
: | Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
: | http://www.fi.muni.cz/~kas/                         GPG: 4096R/A45477D5 |
: > That's why this kind of vulnerability is a concern: deploying stuff is  <
: > often about collecting an obscene number of .jar files and pushing them <
: > up to the application server.                          --pboddie at LWN <

-- 
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| http://www.fi.muni.cz/~kas/                         GPG: 4096R/A45477D5 |
> That's why this kind of vulnerability is a concern: deploying stuff is  <
> often about collecting an obscene number of .jar files and pushing them <
> up to the application server.                          --pboddie at LWN <