Poslední příspěvky1
Server / Re:QEMU nad LVM se zasekává
« Poslední příspěvek od Michal Šmucr kdy Dnes v 12:33:46 »Ú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?
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?
