Přesně jak říká RDa, někde v dmesg by mělo být v tom čase nejspíš ještě něco dalšího, pokud se FS opravdu přepnul do R/O.
Jinak jestli tam nic nebude a samovolně se to vrátí do původního stavu a loguje to dál, tak bych tipoval na nějakou periodickou úlohu, co pracuje s diskem nebo FS.
Napište nám, co máte za FS. Případně vylistujte aktivní timery ze systemd přes:
sudo systemctl list-timers
Skoro vždycky tam v distribucích bývá - fstrim.timer, co spouští fstrim.service
To offline trimování celého disku může chvíli trvat a podle množství LBA rozsahů a konkrétního hardware to může v nějakých extrémnějších případech klidně až na desítky vteřin zazdít veškeré ostatní I/O operace.
V tu chvíli jestliže máte nastavené persistentní logování na disk (do /var/log/journal), tak službě journald vyprší timeout a emituje podobnou hlášku.
Jinak se můžete samozřejmě zpětně podívat, kdy se to případně spouštělo a jestli to sedí s výskytem té chyby:
sudo journalctl -u fstrim.timer
A pokud byste to chtěl dočasně vypnout na vyzkoušení, dá se to také zakázat:
sudo systemctl disable fstrim.trimer
Podobné periodické úlohy mívá i Btrfs. V některých distribucích má rovnou nastavené timery pro balance a scrub. Také pokud máte třeba přes snapper dělané periodické Btrfs snapshoty, tak jejich čištění může celý fs také na pár vteřin zaseknout, zvlášť pokud se používají dohromady s kvótami.
11 Odpovědí
15146 Zhlédnutí