Zalozil jsem bug u Gentoo: https://bugs.gentoo.org/940751
jsou tam postnuty vysledky ze sysrq, a hnije to v kernelu, podle:
# 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
[/quote]
Díky za další detaily. Jasně, synchronizuje se writeback cache a nemůže to zapisovat, všechny vrstvy včetně toho finálního qemu procesu pak čekají.
Mě to pořád vede spíš k tomu, že je tam problém buď s MD, nebo s disky. Přestože by to za normálních okolností po timeoutu, kdy zařízení neodpovídá, měl vzdát a pokračovat jen s tím zbylým z mirroru. A jasně budou tam nejspíš ještě libahci, ahci v případě SATA disků.
Co je každopádně divné (nebo by to opravdu nahrávalo nějakému bugu) je to, že to neemituje jedinou divnou kernelovou hlášku.
Nic.. jsem zvědavý, co to finálně způsobuje, nebo jestli se to povede ještě reprodukovat s jinými jádry a vypnutým write mostly.
dm tohle?
Ano, přesně tohle jsem myslel.
Za normálních okolností je ten LV ACTIVE. Je tam mechanismus, že když je problém se zařízením(i) pod ním, tak nezruší ty své devnody, ale jen se přepne do režimu SUSPENDED a všechny procesy nad ním čekají v uninterruptible wait (D) stavu.
Jak jsem zmiňoval, tak mě se na specifické konfiguraci stávalo to, že nastal problém, přeplo se to do SUSPENDED. Nicméně poté, kdy se zařízení pod LVM vrátilo do funkčního stavu, tak už se to nevrátilo do ACTIVE modu, mrznuly lvs, pvs atd. Ale když se to vynutilo přes dmsetup resume <dev>, tak se dopsaly všechny věci a normálně to pokračovalo dál.
Ten LOOP je tam takto:
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.
Jasný chápu, obešel jsi to docela vtipně, díky za vysvětlení. Já to jen za začátku nepochopil, jak je to do ten loop zapracovaný a že máš v QEMU přímo oddíl bez qcow image.
Nechci se v tom úplně rochnit, tím že je to víceméně off-topic a podle ten loop device v tom problému nebude hrát roli..
Ale WinXP SP3 stoprocentně bootují i s prvním oddílem od 1MiB. Kdysi jsem to řešil v komerčních migračních nástrojcíh z HDD -> SSD (Paragon, Acronis). Podobně, když jsem instaloval VM na běh nějakých starých aplikací ve VMWare nebo QEMU/KVM. Ale tam jsem to dělal tak, že jsem si před instalací Windows připravil prázdné, neformátované 0x07 partitiony zarovnané na 1MB (třeba pomocí linuxového fdisku, nebo diskpart z novějších Windows) a pak to nechal při instalaci XP SP3 zformátovat jejich instalátor, co si pak nainstaloval i zavaděč a normálně to šlape.
Tohle je z jedné image, co jsem našel doma..
https://pastebin.com/raw/DFXc1Qh2Akorát ta zmíněná migrace existujícího Windows disku z 4K na 1M zarovnání se mi nikdy nepodařila standardními nástroji (dd, partclone), nebootovalo to, nezkoumal jsem to moc dál a měl jsem k dispozici boot CD s Paragonem, který to vyřešil uspokojivě.
Poslední příspěvky