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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
