Zamrzani USB disku

[Dan Lukes]

S Dansa wrote:
> pokud k pocitaci s FreeBSD 10.2/i386 pripojim USB disk
> WD Elements 1.5 TB (VID 0x1058, PID 0x10b8, bcdDev. 0x1012),
> pak pri praci s velkym mnozstvim malych dat externi disk
> po chvili na cca 62 sekund zamrzne - LED sviti, data
> netecou. Pokud aplikace neskonci s chybou, pak se po onech
> 62 s vse rozjede, tj. pokracuje, kde skoncila

No, to muze byt jak chyba ovladace USB (ve vztahu ke konkretni 
hardwarove konfiguraci) tak chyba firmware disku.

Pricemz v obou pripadech to nejspis bude mit povahu race-condition 
zavisle na konkretni sekvenci a timingu vzajemne komunikace.

Takze se to bude dost blbe ladit.

> - pri primem pristupu na nenamountovany disk k zamrznuti
>    nedojde (dd if=/dev/da0[p1] of=/dev/null bs=1m)

To je striktne sekvencni cteni, tedy "uzivaci" pattern zcela nepodobny 
"normalnimu" provozu. Takze nam to rika jen tolik, ze "takhl ejednoduse 
to nepujde".

> - pri opakovanem spusteni "tar cvf /dev/null /mnt/src" se
>    vypis zastavi pokazde nekde jinde

To je dalsi indicie k hypoteze o race-condition, nenaznacuje ale kde. 
Jedine pozitivum je, tedy pokud to sice zamrzne v ruznejch chvilich, ale 
pokazdy, ze tu je nejaky postup, kterym se da relativne spolehlive 
overit, zda problem trva.

> - na relativne novem DELL Precision T1700 USB disk pod
>    FreeBSD 10.2 take zamrzal (konfiguraci PC nevim, mohl
>    bych zjistit). Disk byl pripojen k rozhrani USB3

To muze a nemusi byt odlisna hardwarova konfigurace. V druhem pripade 
nejde o nezavislej test.

> - pouziti FAT (msdosfs) situaci zhorsi (zamrznuti > 70 s)

Jiny FS muze znamenat jiny pristupovy pattern, ale taky to muze byt 
daleko jednodussi - treba byl FAT formatovany jen s odlisnou velikosti 
bloku a se stejnou by vysledky byly obdobne.

> - pokud byl na disku FAT oddil s rozbalenym "src" stromem
>    FreeBSD 10.2 pak pri cteni (tar cvf /dev/null...)
>    na Debian Wheezy live (Thinkpad T60p) a MacOS X
>    10.4.11/powerpc (obstarozni Mac Mini) k zamrzani
>    nedochazelo. Na FreeBSD 10.2/i386 ano
(a obdobne body zminujici OpenBSD, Windows)

To az tak moc neodhaluje, odlisne system mohou a nejspis maji prostupy 
ke stejnemu FS implementovane ruzne. Porad muze jit jak o problem prace 
s radicem USB, tak o problem firmware disku.

> - vypis smartctl sice mam, ale nevim, mohu-li mu duverovat

Pokud data dokazal nacist, tak spis nebudou zcela nesmyslny. Obzvlast 
pokud se omezis na "cooked" hodnoty. Nicmene, pro tyhle ucely spis 
nepredpokladam, ze by ze S.M.A.R.T vypadlo neco uzitecnyho.

  -------------

Takze co ?

Genialni rada zadna. Pro zacatek bych zjistil co se deje na USB zarizeni 
v okoli pauzy. To znamena pouzit usbdump pro zachyceni komunikace a 
nasledne posledni wireshark pro analyzu zachycenych dat.

Pokud bude pauza probihat behem otevreneho pozadavku (a tedy se bude 
cekat na odpoved disku) pak to drhne "v disku". Pokud behem pauzy zadna 
otevrena USB transakce probihat nebude, v disku to neni.

Ne, ze by nektera z obou moznosti primo vedla k rozreseni "kdo za to 
muze" nebo "co s tim". Sed divide et impera.

Dan