Administrace komentářů

eeee, nemyslel som io_cancel. Ospravedlnujem sa, skusim to sformulovat trosku inak.

- Ak je "naspodu" raid5 a podobne (stripe + parita), tak toto spravanie je viac nez len podozrive + echo "check" > /sys/block/md*/md/sync_action nesmie ukazat nieco ine ako 0 (slovom nula) v /sys/block/md*/md/mismatch_cnt

- Ak je "naspodu" raid1 (mirror, popripade kobinacia ako raid10), tak "by design" sa mozu tie dva disky lisit. Preto napr distribucie s automatickou kontrolou md-raid ignoruju mirror.

Nemal som pouzit nazov "zrusena" I/O, ale skorsie nepotrebna / zahodena. Priklad:

1) Je malo pamate a VM sa rozhodne nejaku stranku dat do swapu. Toto vyprodukuje dve I/O operacie a je celkom dobra sanca, ze sa APP prebudi a zapise do stranky (ked je malo pamate). VM si danu stranu oznaci ako "dirty" a neriesi, co sa stalo so zapisom. Realne moze jedna DMA operacia dobehnut s povodnymi datami a druha s novymi, alebo jedna z nich nedobehne vobec (ked VM povie, ze to uz nepotrebuje). V realnom stave nie je dovod z takeho miesta citat, takze sa to nejak neriesi, no block level backup bude ukazovat rozdiel (podla toho z ktoreho disku a md rozhodne citat).

2) Nejaka app ma "memory mapped" subor. Do suboru priebezne prihadzuje data a manager pamate ich prehadzuje do suboru. Tak isto sa moze stat, ze sa data zmenia a na diskoch nie su do dalsieho zapisu rovnake data. Tato situacia by mala trvat len kratko, ale zalezi na obieme zmenenych dat + ak sa napr. nespravne signalizuje vyrabanie snapshotu filesystemu (toto je snad uz konecne fixnute v LVM), tak dany blok sa v aktualnom stave "zafixuje".

3) "memmory mapped" subor je po zmenach, ktore sa ciastocne zapisali vymazany. (toto musim pozriet, ci to stale tak funguje) Data sa uz nebudu zapisovat a obsadene miesto sa oznaci ako volne. Tak isto je toto skorsie az race condition, ale moze nastat ...

Ak sa cita vsetko, vratane miest, ktore nie su validne (volne miesto, este nezapisane, etc.). Tak vysledok zalezi od toho, z ktoreho disku sa raid rozhodne precitat. Dost zaujimave citanie na tuto temu je jeden debian bug report. Konkretne odpoved #41.

V pripade md-raid(-u) v mode mirror check pola moc nepomoze. Jednine ako skontrolovat, ze vsetko ide ako ma, je kontrolovat aj uroven pod. Ked je moznost, tak aj uroven nad:

- stav diskov (pravidelne smart -t short, smart -t long, smart -a / mozem vyzdielat moj konfig, ak je to zaujimave)
- samotne pole, ci nehlasi I/O errory a je spravne zlozene, etc.
- checksumy na urovni filesystemu *
- z casu na cas memtest (len vazne pri velkej paranoi, alebo podozreni na problem)

* (ja vramci paranoje kontrolujem vsetky staticke subory a cast dynamickych kontrolujem oproti katalogu / dobuducna mam plan prejst na fs s checksumami dat, zrejme btrfs)

FYI: zbehol som na jednej mojej masine check a mismatch_cnt je nenulove. Ked budem mat cas, tak s tym skusim kus pohrat :o)