Dotaz: SW RAID block?

[iKoulee]

Mam problem se SW raidem, pokusil jsem se spustit opravu:

echo "repair" > /sys/block/md7/md/sync_action

a vysledek je:

md7 : active raid5 sdq[0] sdt[3] sds[2] sdr[1]
      2929654272 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      	resync=DELAYED

stejne tak se mi kupi procesy v "D" na stejnem zarizeni, namatkou:

root      7741  0.0  0.0      0     0 ?        D    17:33   0:00 [md7_resync]
root     10072  0.0  0.0      0     0 ?        D    06:01   0:05 [flush-9:7]
www-data  5695  0.0  0.0 105768  2880 ?        D    Aug12  12:06 nginx: worker process

To je nejaka nova feature md modulu, kterou jsem nepochytil a nebo pruser?

Kernel 3.3.6 Vanilka

radic je tam 3ware, modinfo:

version:        2.26.02.014
license:        GPL
description:    3ware 9000 Storage Controller Linux Driver
author:         LSI
srcversion:     FFDDEAA1E82198840863F6B
alias:          pci:v000013C1d00001005sv*sd*bc*sc*i*
alias:          pci:v000013C1d00001004sv*sd*bc*sc*i*
alias:          pci:v000013C1d00001003sv*sd*bc*sc*i*
alias:          pci:v000013C1d00001002sv*sd*bc*sc*i*
depends:        
intree:         Y

lspci:

07:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID (rev 01)

z DMESgu:

[744660.483322] md: requested-resync of RAID array md7
[744660.496528] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[744660.509647] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for requested-resync.
[744660.523153] md: using 128k window, over a total of 976551424k.

v Event logu radice jsem nic zajimaveho nenasel mimo stiznosti ze se nemuze spojit s BBU, ale to bude tim ze tam ta baterka neni.

Nejvetsi problem je, ze me ani moc nenapada co googlit

Odpovědi

[Sten]

V dmesg toho bude nejspíš víc, třeba něco jako timeouty operací na discích nebo resetování SATA/SAS portu

[iKoulee]

V dmesg toho bude nejspíš víc, třeba něco jako timeouty operací na discích nebo resetování SATA/SAS portu

Kdyby tam neco podobneho bylo, tak se tady tak blbe neptam

Nicmene neco zajimaveho jsem prece nasel, problem se mi samovolne zreplikoval na jinem stroji a zda se ze souvyslost bude s automatickou verifikaci, po jejimz spusteni se zacali obevovat problemy.

[679789.325878] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=0.
[679789.341010] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=1.
[679789.356265] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=2.
[683429.045849] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=3.
[683429.060751] 3w-9xxx: scsi0: AEN: INFO (0x04:0x003D): Verify paused:unit=1.
[683429.080209] 3w-9xxx: scsi0: AEN: INFO (0x04:0x003D): Verify paused:unit=2.
[683429.112325] 3w-9xxx: scsi0: AEN: INFO (0x04:0x003D): Verify paused:unit=0.
[683444.228048] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=0.
[683444.242836] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=1.
[683444.257097] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=2.
[692301.856198] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=1.
[692302.176528] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=3.
[692502.055856] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=2.
[692502.470393] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=4.
[692877.574727] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=0.
[692877.986611] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=5.
[708679.574298] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=4.
[708679.914292] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=6.
[709281.697751] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=5.
[709281.964634] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0029): Verify started:unit=7.
[709940.890510] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=3.
[724553.718862] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=7.
[733743.150383] 3w-9xxx: scsi0: AEN: INFO (0x04:0x002B): Verify completed:unit=6.

[trubicoid]

neceka mdadm az dobehne nejaka ta verifikace 3w? to by pak rikal delayed, ale jsem myslel, ze by duvod napsal do dmesg; ja mivam treba:

md: delaying data-check of md2 until md0 has finished (they share one or more physical units)

a asi jeste nechapu, ten RAID je md ne v 3w? mebo ten md je nad RAIDem v 3w? proc tedy jako poustet verifikaci ve 3w?

[iKoulee]

je to SW, je to historicky stroj, kde uz se par radicu vystridalo. Skoncilo to sice se radicem ktery umi HW raid, ale nepouziva se, v podstate nastaveni radice bylo +- default snad jen s vyjimkou povoleni cache, presto ze neni vybaveny BBU

uz radove roky to fungovalo v celku v pohode ve stavu v jakem to je, a nedavno se obevil tenhle problem, ale bez prime zavyslosti na nejakem patrnem vnejsim podmetu (aktualizace jadra probihaji pravidelne, ale neobevilo se to primo po zadne z nich, nebo jine podobne pricine)

[trubicoid]

no podle mne si 3w mysli, ze by mel RAID kontrolovat on a tim blokuje mdadm; toto jsem vygooglil:

kernel: 3w-xxxx: scsi0: AEN: INFO: Verify started: Unit #0. Message can be ignored. It indicates that the tw_cli start verify has been run.

nepousti se to nahodou z cronu treba? a mas nainstalovany tw_cli? tedy sw, ktery kontroluje 3w RAID? mozna on to tam sam dal cron job

ja bych ten 3ware soft odinstaloval a je to

[iKoulee]

tw_cli mam, z cronu nic nedela(debiani balik jsem si buildil sam), vsechno si resi radic interne, takze jsem aktualne vypnul verifikaci v biosu radice a restartnul stroj, protoze tech zamrzlych procesu bylo uz mnoho, tak uvidim a budu doufat

Osobne si zacinam myslet, ze je to bug v nejake novejsi verzi ovladace a kazi se to jen pri nejake shode nahod, tipuji verifikace zrovna cachruje se slice, kterou chtel cist/zapsat system

[Trubicoid2]

No to by mohlo pomoct. V tom biosu nemůžeš nějak úplne raid vypnout? Jestli to nepomůže, tak bych jeste odinstaloval tw_cli, stejne na nic neni, ne?

[iKoulee]

Uplne to nejde ty disky jsou exportovane jako simple volume, ale primy pristup k nim neni, tw_cli zustava, aby se dalo obcas neco vytahnout z radice, ale je to jen staticky slinkovana binarka, ktera nema zadny daemon mod, jen si umi prez rozhrani v /dev pokecat s tim radicem

[homunkulus]

a co rika

cat /proc/mdstat

?

[iKoulee]

a co rika

cat /proc/mdstat

?

Bylo to nahore asi jsem to sepsal trochu neprehledne.

md7 : active raid5 sdq[0] sdt[3] sds[2] sdr[1]
      2929654272 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      	resync=DELAYED

[alkoholik]

Ty mas v celem mdstat jenom md7? Ze ty jsi neco umaznul!
Jinak DELAYED je "nova" ficura, ktera spusti synchronizaci disku, az kdyz tam nekdo zapise prvni data. Ale ty mas asi jiny problem..

[dustin]

Taky bývá delayed, když mezitím probíhá synchronizace jiného pole. Proto by to chtělo celý výpis mdstat.

[alkoholik]

Pravda, kecam. Cekani na prvni zapis je PENDING. DELAYED skutecne ceka jenom na sync jineho pole.

[iKoulee]

Ty mas v celem mdstat jenom md7? Ze ty jsi neco umaznul!

Coz o to, ani tak neumaznul jako spis nezkopiroval, protoze tam neni nic duleziteho a jen by to zabiralo misto.

DELAYED obvykle ceka na synchronizaci jineho pole na stejnem disku, coz ovsem neni naz pripad, protoze jsou pouzita cela blokova zarizeni a ne partitions.

Personalities : [raid1] [raid10] [raid6] [raid5] [raid4] 
md3 : active raid5 sda3[0] sdb3[3] sdc3[2] sdd3[1]
      2894060544 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md1 : active raid1 sda2[0] sdd2[1]
      10482304 blocks [2/2] [UU]
      
md0 : active raid10 sda1[0] sdb1[3] sdc1[2] sdd1[1]
      2088320 blocks 64K chunks 2 near-copies [4/4] [UUUU]
      
md2 : active raid1 sdc2[0] sdb2[1]
      10482304 blocks [2/2] [UU]
      
md7 : active raid5 sdq[0] sds[3] sdr[2] sdx[1]
      2929654272 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md8 : active raid5 sdt[0] sdw[3] sdv[2] sdu[1]
      2929654272 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md5 : active raid5 sdf[0] sdm[3] sdl[2] sdk[1]
      2928671232 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md6 : active raid5 sdn[0] sde[3] sdp[2] sdo[1]
      2928671232 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md4 : active raid5 sdi[0] sdj[3] sdh[2] sdg[1]
      2928671232 blocks level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
unused devices: <none>

[dustin]

V tom výpisu už žádné delayed nevidím, všechna pole vypadají v pořádku. V čem je tedy problém?

[iKoulee]

uz jsem psal o kousek vis, ze jsem to musel restartnout, pac uz na tom bylo vyhnitych mnoho procesu, tedka je to v pohode, problem je, ze tohle uz je po druhe co se problem opakoval a pokud mozno nerad bych, aby se opakoval po treti.

[iKoulee]

Tak asi "vyreseno", je to zajimave, ze se to zacalo projevovat ted z nenadani. Nicmene povrtal jsem se v backtrace a stoural se ve zdrojacich jadra a dospel jsem k nazoru, ze za vsechno muze BKL, tedy konkretne jeho neexistence. Zkusil jsem downgrade kernelu na 2.6.35 stable, tedy posledni LTS bred odstranenim BKL a posledni mesic je bez problemu. Patch bohuzel stvorti nedokazu, protoze cela zalezitost zamykani mezi driverem a md modulem je pro me trochu vyssi divci, kdyz bude cas a prostor nekde spustit kernel v ladicim rezimu tak snad poslu bug-report.