QEMU nad LVM se zasekává

[RDa]

Ahoj, posledni dobou se me deje podivna vec - QEMU proces se zasekne v neprerusitelnem sleepu (top: D state).

Konfigurace stacku je tahle:

- gentoo linux 6.11.0
- md raid1 mirror (hdd+ssd)
- lvm (pv/vg/lv)
- losetup ( posun o 1 sektor )
- qemu (9.0.2)
- winxp

Kdyz se to zasekne, tak nefunguje ani RDP z guestu (winxp), a celkove Qemu zhebne (nefunguje ani remote spice klient - a ani pripojeni na lokalni monitoring socket).

A co vic, nefunguje ani lvs prikaz na vypsani logical volumes. Proste taky D state a zasekne se.

strace lvs - me rikal posledne, ze to pouziva async io.. tak jsem podezrival tohle - pridal jsem do qemu option na disk ve tvaru ,aio=threads, ale neni s tim rozdil. Po tydnu se to ted seklo zas.

Stav je to docela neprijemny, protoze se host os neda vypnout ani restartnout - musim shodit ostatni VM, vsechny sluzby a pak to navrdo resnout, doufajic, ze systemovy oddil prezije (zatim nizsi jednotky tvrdych resetu to dalo... ext4 nad lvm).

Mam podezreni ze se sekne nejake uzamykani v jadre - ale netusim kde se divat.

Na starem jadru co tam bylo predtim to nedelalo zadny problem, ale to tam vracet nechci (6.6.52), plus byla nejaka podstatna zmena konfigurace, abych novym jadrem pokryl a sjednotil vicero stroju.

Jak by jste ladili takovou vec, co se objevi jednou za tyden? (tedy, pred tydnem jsem to potkal asi 3x v rade prvni den.. pak vznikl dodatek qemu konfigurace s aio=threads)

v lsof nejak nepoznam, na ktery fd to delalo jakou operaci? nebo jinde v sysfs? Neco jako show in-flight syscalls ?

Je fakt blby ze neni nejaky unlocker, na tyhle kernel-side locknute IO.
Klidne za cenu ze ta aplikace dostane error, spatna data nebo bude ukoncena v momente navratu syscallu.

EDIT:
pridal jsem sysrq podporu do jadra, az to padne priste at muzu udelat ten w command:
https://www.suse.com/support/kb/doc/?id=000016919

[Reklama]

[Michal Šmucr]

Úplně si nemyslím, že by šlo o nějaké špatné, nebo chybné zamykání. Přestože tam samozřejmě může být bug, regrese v jádře (zvlášť jestli máš rolling distribuci), tak mi to spíš přijde jako nějaký problém s konkrétními blok zařízeními v těch spodních vrstvách, čeká to na nějaký I/O timeout, který ze propaguje výš a poslední userspace proces, co je použil zůstává v D state.
Měl jsem např. podobné zátuhy s iSCSI externím disk. polem (hw -> target -> initiator -> multipath a LVM -> fs).

Tím, že blbnou i LVM příkazy jako lvs atp., tak bych z toho asi rovnou vyloučil QEMU a jiné userspace procesy, jejich zátuh už bude jen logický důsledek.
Kdyby to nastalo znovu, tak bych asi zkusil pro info.
- zkontrolovat dmesg (hlášky o timeoutech pro operaci na md nebo blok. zařízeních)
- spustit /sbin/dmsetup info + zkouknout, jestli není nějaké zařízení SUSPENDED místo ACTIVE
- podíval se, v jakém stavu jsou fyz. bloková zařízení pod tím raidem
např. cat /sys/block/sda/device/state a mělo by to vypsat running

Co bych případně zkusil dál.
- v případě, že tam bude dmsetup info vypisovat nějaké suspended zařízení, můžeš ho zkusit znovu manuálně nahodit přes dmsetup resume
- projet SMART u těch disků, jestli se tam nekumulují nějaké chyby přenosu na sběrnici
- nedělá se v tu dobu něco jako periodický fstrim (pokud to přes tu kaskádu vůbec proleze)?
- koncentroval bych se na divnosti
Vím, že jste ten hybrid mirror s HDD+SSD mirrorem a write-mostly zmiňovali s F. Kučerou. I když by to asi mělo fungovat, pořád mi přijde, že jsou to zařízení s výrazně jinou charakteristikou a nepoužívá to úplně moc lidí (-> nebude to úplně masivně testované). V krajní možnosti, kdybych s tím nemohl hnout, tak bych po zálohování asi dočasně zfailoval přes mdadm jeden z těch disků a nechal to nějakou dobu běžet v degradovaném režimu, jestli to nebude mít pozitivní vliv s jedním zařízením.
- mrknul bych se na timeouty
Např. konkrétní SSD může mít nějaký déle běžící interní GC, který teoreticky způsobí, že to na chvíli vyhnije a nezapisuje.
U pokusů s timeouty mám typicky dvě strategie, buď výrazně zkrátit a čekat, jestli se nezvýší výskyt chyby, nebo rozumně prodloužit, pokud už tuším, a zkouším, jestli to pomůže.
Timeouty myslím třeba nastavení fyz blok. zařízení /sys/block/sda/device/timeout, nebo u NVME disků pak nastavení v modulu nvme_core (dá se poslat jako parametr jádra).
Nadto některé NVME disky mají také možnosti ovlivnit jejich chcípání a přecházení mezi power staty (APST) přes nvme set-feature.

Jen takový můj dump k tématu, může to být spoustou věcí..

P.S.: Co dělá ten losetup s offsetem 1s? To jsem nějak nepochopil, jakože tam je ještě další loop device jen kvůli tomu posuvu?

[RDa]

Zalozil jsem bug u Gentoo: https://bugs.gentoo.org/940751

jsou tam postnuty vysledky ze sysrq, a hnije to v kernelu, podle:

Kód: [Vybrat]

# ps auxf | grep D
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      7358  0.0  0.0      0     0 ?        D    11:32   0:00  \_ [kworker/u16:0+loop0]
root      9444  0.0  0.0      0     0 ?        D    11:52   0:00  \_ [kworker/u16:4+flush-251:4]
v dmesg zadny error neni, disky jsou lokalni a bez chyb ve smartu

raid je ok:

Kód: [Vybrat]

# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md127 : active raid1 sdb2[2](W) sda2[0]
      976497664 blocks super 1.2 [2/2] [UU]
      bitmap: 3/8 pages [12KB], 65536KB chunk

unused devices: <none>

dm tohle?

Kód: [Vybrat]

# dmsetup info vg0-vmWinXP
Name:              vg0-vmWinXP
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      251, 4
Number of targets: 1
UUID: LVM-KVkZOEFX23Qn7J0YkaFkaSUxt5KAvpHnegGxabY0xaBAHNOpssPEPi7WY6lfC36W

Ten LOOP je tam takto:

Kód: [Vybrat]

# losetup -l
NAME       SIZELIMIT  OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0         0 1016320         1  0 /dev/dm-4   0     512

... tvoren prikazem:

Kód: [Vybrat]

losetup -o $(( 512 * ( 2048 - 63 ) )) "$DRIVE_BOOT" "$DRIVE_FILE"
A je to z duvodu, aby C: partisna byla 4K aligned (prakticky je 1MiB aligned). Na LVM je modifikovany obraz disku s winXP, kde byla prvni partisna posunuta na zarovnanou pozici - sektor 2048, ale ten originalni bootloader si s tim neporadi a nebootuje to - pak uz jsem nedohledal jak opravit bootovani, protoze:

... jsem vymyslel rovnak na ohybak: vzal tech 63 sektoru od pocatku disku (kde je bootloader), nakopiroval je pred hranici prvni partisny, a ve QEMU bootuji z toho posunuteho loopdevice. Vysledek je:
- guest si mysli ze ma C: zacinajici na 63 sektoru a tedy bootuje ok
- host ma data zarovnana

Ta LVM partisna tedy obsahuje dve partition tables, jedna je na zacatku s 2048 offsetem pro C:, druha je pred koncem 1M bloku s 63 offsetem pro C:, prostredek prvniho 1M bloku je pak nevyuzit.

[PCnity]

Aky zmysel ma ten loop dev nad LV? Nie je mozne spavit LV so spravnym alignemntom a pouzit priamo ten pre QEMU? Cisto v zmysle ze kazda vrstva navyse je potencialom pre dalsie bugy.

[RDa]

Aky zmysel ma ten loop dev nad LV? Nie je mozne spavit LV so spravnym alignemntom a pouzit priamo ten pre QEMU? Cisto v zmysle ze kazda vrstva navyse je potencialom pre dalsie bugy.

Precti si to jeste jednou, vysvetlil jsem to v predesle odpovedi, neco vice pak zde: https://superuser.com/questions/242313/can-windows-xp-be-installed-on-a-partition-that-starts-at-sector-64-on-advanced (a to mam SP3, ale nebootuje to odjinud, url na MS KB uz nefunguje.. proste jsem to vyresil nejsnadneji jak to slo)

Imho LVM nic takoveho sam neumi a jeho PE jsou nasobne vetsi nez rozmery/posuny o kterych se zde bavime.

Ze je dalsi vrstva, resp. specificka kombinace vrstveni nachylna na bugy - budiz. Ale od toho tady jsem a chci aby se prislo na to v cem se to sekne - a opravilo se to. Verim ze to pomuze nejenom me ale i jinym.

[Reklama]