Problém se SMR disky Seagate Archive 8TB

Úterý Květen 22 21:05:13 CEST 2018

Dd,

při čtení toho dmesg výpisu mě zarazil tento řádek:

[65260.525627] scsi target6:0:2: enclosure_logical_id(0x5003048011920600), slot(2)

Zdá se, že SAS vrstva ví o tom, ve kterém "šuplíku" došlo k
problému. Napadlo mě, že by snad ten šuplík uměla "vypnout"? Ale
vůbec nevím, zda lze nějak ty šuplíky ovládat (že by něco jako
generic SCSI zařízení, kterým se dal řídit changer pro pásku)?

Nikdy jsem to nedělal a zkušenost s tím nemám, ale třeba by šlo
něco tímto směrem dále zkoumat?

Četl jsem ale, že už to máte (alespoň z větší části) vyřešené,
tak to, kdyžtak, vezměte jen jako povšimnutí...

Zdraví
Honza Marek

On Tue, Apr 03, 2018 at 11:30:25AM +0200, Jan Kasprzak wrote:
> 	Dobrý den,
> 
> mám následující problém s disky Seagate Archive 8TB, ST8000AS0002
> (4 KB sektory, SMR zápis, podle nějakých recenzí na webu mají cca 20 GB
> prostoru pro cache náhodných zápisů):
> 
> 	Při zálohování na tyto disky se čas od času stane, že se některý
> z disků náhodně odpojí. Když se to stane, jádro vypíše do logu chyby SCSI
> vrstvy (přikládám níže) a disk přestane být v systému vidět (udev smaže
> i jeho uzly v /dev). Následně si pochopitelně začne stěžovat filesystém
> (ext4), že mu zmizel disk, a že aborting journal, atd.
> 
> 	Máme dva různé zálohovací stroje, každém je typicky 6 takovýchto
> disků, průměrně pozorujeme dvě takováto odpojení za týden (čili u jednoho
> disku to vychází na střední dobu 3 týdny mezi závadami). Disků máme tak
> cca 15, dělají to nejspíš všechny. Na jednom serveru jsou disky na SAS
> backplane s řadičem LSI SAS2308 (driver mpt_sas), na druhém serveru jsou
> tytéž disky na lokálním AHCI. Čili řadič a jeho driver bych snad vyloučil.
> 
> 	Některé disky toto dělají častěji než jiné, ale to přikládám
> různému charakteru dat, která se na ty jednotlivé disky zálohují.
> 
> 	Největší podivnost na tom je, že když toto nastane, tak ten slot
> pro disk přestane být použitelný - nepomůže disk vytáhnout a zpět zasunout,
> nepomůže vložit jiný disk, nepomůže "echo 0 0 0 > scan" v příslušném
> adresáři sysfs. Dokonce nepomůže ani reboot přes kexec, ani reboot přes
> BIOS. Je potřeba ten počítač vypnout (shutdown -h nebo tlačítkem) a pak
> teprve zapnout. Což zase směřuje k řadiči, ale že by se takto choval
> LSI SAS i AHCI, to se mi nezdá.
> 
> 	Jiné zálohovací disky toto zdá se nedělají.
> 
> 	Zkoušeli jsme různé kernely (OS je CentOS 7), zkoušeli jsme
> snižovat hloubku NCQ fronty až na 1, zkoušeli jsme snižovat max. velikost
> requestu, nic nepomohlo.
> 
> 	Potkali jste se někdo s něčím takovým? Co dalšího vás napadá,
> že by se dalo vyzkoušet? (nápady typu "použít větší kladivo"
> a "příště nekupovat Seagate" mě pochopitelně už napadly :-).
> 
> 	Díky,
> 
> -Y.
> 
> A ještě zmíněný kus dmesg:
> Mar 29 02:43:29 blackbox kernel: [65260.525550] sd 6:0:2:0: attempting task abort! scmd(ffff880258a42000)
> Mar 29 02:43:29 blackbox kernel: [65260.525572] sd 6:0:2:0: [sde] CDB: 
> Mar 29 02:43:29 blackbox kernel: [65260.525582] Synchronize Cache(10): 35 00 00 00 00 00 00 00 00 00
> Mar 29 02:43:29 blackbox kernel: [65260.525607] scsi target6:0:2: handle(0x000a), sas_address(0x4433221101000000), phy(1)
> Mar 29 02:43:29 blackbox kernel: [65260.525627] scsi target6:0:2: enclosure_logical_id(0x5003048011920600), slot(2)
> Mar 29 02:43:29 blackbox kernel: sd 6:0:2:0: attempting task abort! scmd(ffff880258a42000)
> Mar 29 02:43:29 blackbox kernel: sd 6:0:2:0: [sde] CDB: 
> Mar 29 02:43:29 blackbox kernel: Synchronize Cache(10): 35 00 00 00 00 00 00 00 00 00
> Mar 29 02:43:29 blackbox kernel: scsi target6:0:2: handle(0x000a), sas_address(0x4433221101000000), phy(1)
> Mar 29 02:43:29 blackbox kernel: scsi target6:0:2: enclosure_logical_id(0x5003048011920600), slot(2)
> Mar 29 02:43:32 blackbox systemd-logind: Removed session 60079.
> Mar 29 02:43:32 blackbox kernel: [65264.411225] sd 6:0:2:0: task abort: SUCCESS scmd(ffff880258a42000)
> Mar 29 02:43:32 blackbox kernel: sd 6:0:2:0: task abort: SUCCESS scmd(ffff880258a42000)
> Mar 29 02:43:32 blackbox kernel: blk_update_request: I/O error, dev sde, sector 7814459304
> Mar 29 02:43:32 blackbox kernel: Aborting journal on device sde1-8.
> Mar 29 02:43:32 blackbox kernel: sd 6:0:2:0: [sde]  
> Mar 29 02:43:32 blackbox kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Mar 29 02:43:32 blackbox kernel: sd 6:0:2:0: [sde]  
> Mar 29 02:43:32 blackbox kernel: Sense Key : Not Ready [current] 
> Mar 29 02:43:32 blackbox kernel: sd 6:0:2:0: [sde]  
> Mar 29 02:43:32 blackbox kernel: Add. Sense: Logical unit not ready, cause not reportable
> Mar 29 02:43:32 blackbox kernel: sd 6:0:2:0: [sde] CDB: 
> Mar 29 02:43:32 blackbox kernel: Write(16): 8a 00 00 00 00 01 8c d3 8c 58 00 00 00 08 00 00
> Mar 29 02:43:32 blackbox kernel: blk_update_request: I/O error, dev sde, sector 6657641560
> Mar 29 02:43:32 blackbox kernel: EXT4-fs warning (device sde1): ext4_end_bio:317: I/O error -5 writing to inode 104017376 (offset 188416 size 258048 starting block 832205196)
> Mar 29 02:43:32 blackbox kernel: Buffer I/O error on device sde1, logical block 832204939
> 
> 
> -- 
> | 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 <
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux

-- 
Ing. Jan Marek               | Nez mi poslete prilohu .doc, .xls 
University of South Bohemia  | nebo .ppt, prectete si, prosim,
Academic Computer Centre     | WWW stranku uvedenou na poslednim
Phone: +420-38-9032080       | radku signatury...
http://www.gnu.org/philosophy/no-word-attachments.cs.html