rPman

полистать логи до того как стали появляться эти сообщения.

дословный перевод - файловая система стала read only, т.е. только для чтения, а значит каждая попытка записи будет выдавать такую ошибку

Без чтения логов гадать бессмысленно.

bcache (hdd+ssd) и на него файловую систему ext4/xfs, кстати журнал можно так же разместить на ssd, в некотором смысле это наилучшая конфигурация для домашнего пользователя с точки зрения производительности на затраченный рубль.

Можно btrfs, поиграетесь со снапшотами, сжатием и дедупликацией (кстати с последним не поиграетесь, всякие ubuntu из коробки не умеют) но copy-on-write файловые системы могут подкинуть ряд неочивидностей (например базы данных там фрагментируют диск, но это тюнится)

wsl это не конечное решение а просто инструмент, когда вам нужно здесь и сейчас но от windows отказаться почему то не получается, основывать что либо на этом решении я бы не рекомендовывал

Я встречал странные глюки при использовании wsl, файл физически присутствующий на диске не мог быть удален или прочитан (file not found), не мог быть пересоздан (file exists) и т.п., причем это похоже проблема со стороны windows, и лечится рестартом хоста.

Само существование wsl - полезная вещь, но я не верю что майкрософт будет поддерживать полную совместимость, ей это не выгодно... т.е. сначала конечно все будет работать, но когда этим начнут активно пользоваться, как это уже встречалось с майкрософт, что-нибудь поменяется и работать без переделки будет только у них.

p.s. главные возможности linux не только в командной строке и пакетном менеджере (и вылизанном порядке в нем) но и в фичах работы с железом (файловые системы, системы кеширования, работа с памятью,..) чего само собой в условиях wsl нет.

К примеру в определенный момент мне не хотелось перезапускать процесс, запущенный на слабой linux машине, но там заканчивалась оперативная память, считанные гигабайты нехватало, к сожалению hdd диск использовался очень интенсивно (линейное чтение запись) и добавлять к нему нагрузку свопа стало бы фатальным (замедлило бы работ в десятки раз), за пару кликов я запустил nbd сервер на windows, расшарив обычный файл и подключив его на linux поднял своп на нем. Вдумайтесь в абсурдность конфигурации - и Linux это позволяет, когда как с windows это было бы невозможно либо 'дороже' (я знаю про iscsi).

Вы можете представить что поднимаете своп на основе GPU RAM или используете ее как диск? Вы знаете что можете использовать GPU подсистему удаленно, по сети, причем это штатный инструмент (xserver сетевой сервер) без необходимости покупки дорогого серверного оборудования и софта (с большой буквы, ограничение у windows исключительно программное). 10 человек за одной машиной, физически не удаленный терминал (10 мониторов, 10 клавиатур и мышек) без покупки софта, как было бы для windows (спасибо ibik такой софт есть). Вы наверное не пробовали настроить кластер в linux, представьте что вы работаете в окружении представляющем для вас одну машину, но по факту являющейся распределенным кластером (кстати этот инструмент не так эффективен как ручное управление но факт есть факт)

Конечно искать проблему и утечки памяти, можно добавить своп, в ситуациях когда процессы это допускают, это может помочь.

Можно форкать в момент когда процесс убивают (наверное имеет смысл если причина убийства не физический конец памяти а некоторые комбинации настроек лимитов), предварительно освободив занятую память конечно. Т.е. ваш процесс конечно умрет, но перед самой смертью он родит клона, с меньшим потреблением памяти.
p.s. не делайте так, это только от безысходности.

тут как раз обсуждали как отловить момент