Podivne zaseky - jak dal postupovat? [dlouhe]

[Miroslav Prýmek]

Ahoj,

na jednom postarsim low end serveru (HP ML110 G5, 2G RAM) se mi
stala neprijemna vec - zasek procesu v D stavu po pokusu
o zapis na disk.

Necekam, ze bysme tady presne rozresili pricinu, spis bych vas chtel
poprosit o nazor, co byste v takove situaci delali. Sorry za delsi
post, uz tak jsem se snazil psat jenom to nejpodstatnejsi...

Situace je takova, ze na te lokaci je prehistoricky server obsluhujici
jenom 6 stanic (windows domena pres sambu, ldap, dhcp, apod.), ktery
jsem chtel nahradit tim zminenym serverem. Predpripraveny na nem bylo
FreeBSD 10.3-RELEASE, vsechno na ZFS nad dvema disky.
Pri nasazovani se ale server
choval podivne - prvne nekolikrat doslo k samovolnemu resetu. Prvne
byla na vine nejspis zavada na UPSce. Po jeji vymene ale doslo zase
k tomu zminenemu zaseku v D stavu.

Zjistena fakta:

-------------------
Zaseknute operace na jednom z disku:
# gstat -b
dT: 1.011s  w: 1.000s
  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
     0      0      0      0    0.0      0      0    0.0    0.0  ada0
    12      0      0      0    0.0      0      0    0.0    0.0  ada1

Cteni z disku se potom taky zaseklo:
# dd if=/dev/ada1 of=/dev/null bs=1024k

Stejne cteni z druheho disku (ada0) probehlo v pohode.

zpool status nehlasil zadne problemy - ZFS se celkove tvarilo, ze je v
pohode, akorat ceka. A ceka neomezene dlouho... System reagoval,
slo spoustet kde co, ale to bylo mozna z cache nebo druheho - zdraveho - 
disku.

Poces, ktery se zrejme zasekl jako prvni, cekal na tomhle:
# procstat -kk 917
   PID    TID COMM             TDNAME           KSTACK 

   917 100480 python2.7        -                mi_switch+0xe1 
sleepq_wait+0x3a _cv_wait+0x17d zio_wait+0x5b 
dmu_buf_hold_array_by_dnode+0x1ec dmu_read_uio_dnode+0x41 
dmu_read_uio_dbuf+0x3b zfs_freebsd_read+0x3e3 VOP_READ_APV+0xa1 
vn_read+0x165 vn_io_fault+0x10b dofileread+0x95 kern_readv+0x68 
sys_read+0x63 amd64_syscall+0x40f Xfast_syscall+0xfb

Anebo to byl mozna tenhle:
# procstat -t 1673
   PID    TID COMM             TDNAME           CPU  PRI STATE   WCHAN
  1673 100458 python2.7        -                  3  152 sleep   db->db_c

Kazdopadne ostatni procesy v D stavu byly zasekle na zil_commit:

# procstat -kk 1720
   PID    TID COMM             TDNAME           KSTACK 

  1720 100495 bounce           -                mi_switch+0xe1 
sleepq_wait+0x3a _cv_wait+0x17d zil_commit+0x85 zfs_freebsd_fsync+0x9c 
VOP_FSYNC_APV+0xa7 sys_fsync+0x209 amd64_syscall+0x40f Xfast_syscall+0xfb

Na serveru zadne ZIL zarizeni neni, jenom dva disky v zfs mirroru.

No takze jsem logicky pojal podezreni, ze je to chyba disku.
Nekde jsem nacetl, ze ZFS ocekava, ze pripadne failne nizsi vrstva,
takze pokud k tomu nedojde, muze cekat naveky a neresi to.
Nekdo radil zkusit

# zpool set failmode=continue zroot

ale to se zaseklo taky (mozna by to mohlo pomoct, kdyby se to udelalo 
predem, nevim, netusim, nikdy jsem to nepotreboval a netestoval).

Stejne tak se zasekl pokus o vyhozeni disku z poolu. Ani na CAM urovni
se mi to nepodarilo:

# camcontrol eject ada1
Error received from stop unit command

Takze zbyla posledni sance ten disk natvrdo odpojit (porad za behu).
To probehlo v poradku, disk zmizel, dokonce z gstatu zmizely visici
operace, ale ne vsechny - misto tech 12 tam byla jedna :(

Takze nezbylo nez server natvrdo vypnout.

-------------------
Pokusy ex post

Takze jsem dosel k nazoru, ze chyba bude v disku. Jenze SMART nerikal
nic, offline test probehl bez chyby a jakekoli stresstesty jsem se
snazil na disku poustet, vsechno bylo uplne v pohode.

Jeste me napadlo, jestli by to nemohlo souviset s jinou veci - pri
pripojeni na tenhle server se mi obcas stavalo, ze jakoby na sekundu dve
zamrzl a pak jel v pohode dal. Nedoresil jsem, jestli to bylo sitovkou
nebo necim jinym. Bylo by mozny, ze by nejaka chyba v hw nebo v driveru
zpusobila nejake takove cekani, neco v diskovych operacich by spravne
nevytimeoutovalo a ZFS by se tim dostalo do vecneho cekani?! To asi
tezko zjistim :(

-------------------
Co ted?

Ted fakt nevim, co s tim dal :(

  - dost dobre nemuzu riskovat, ze se tohle bude se serverem stavat v
    ostrem nasazeni. Uz proto, ze to vyzaduje tvrdy reset na miste...

  - nedokazu nijak urcit, jestli chyba byla v disku, radici nebo necem
    jinem a jestli se bude opakovat

  - jak jsem psal, pred timhle incidentem sel server do tvrdeho resetu
    asi dvakrat. Mohlo to poskodit zpool tak, aby se choval takhle divne?
    Melo by smysl ho smazat a vytvorit znovu z ciste vody?!

  - 2GB RAM na ZFS je malo, ale zas ne tak malo, aby se stalo tohle (?)
    -> zkusit se ZFS vzdat a jet na tehle lokaci na UFS? (jinde mam ZFS,
    takze udrzovat jednu instalaci s UFS je opruz)

  - zkusit koupit nejaky PCIe SATA radic?

  - udelat nejake dalsi testy?

  - nebo se vykaslat na ozivovani tohodle stareho zeleza a radeji
    presvedcit zakaznika, at koupi novy server (a doufat, ze s nim
    zadne problemy nebudou)?

Nejak se nemuzu rozhodnot, jakou cestou jit - vsechny jsou docela
pracne a s nejistym vysledkem. Co byste doporucovali udelat?
(Vim, ze je to debilni otazka, ale jsem z toho fakt zoufalej, kazda
troska do mlyna by mi pomohla)

Diky predem za jakoukoli radu.


Mirek