18.04 с ядром 4.19.x на SSD Ext4 падает в read only

[AlexanderL]

Проблема появилась пару недель назад:

обнаружил, что SSD с корневой файловой системой перемонтируется в read only из за ошибок (контрольные суммы в inode).
Тесты smartctl и badblocks никаких ошибок не обнаружили.
Грешил на старый SSD, купил новый, перенёс систему на новый SSD - не помогло. 

Немного помогло отключение timeshift - система стабильно падает в RO, когда timeshift читает ВСЕ файлы для backup-а.

Загрузился с LiveUSB, сохранил все rsync-ом, переформатировал партицию, вернул систему rsync-ом на место - падает

Загрузился с LiveUSB, сохранил все rsync-ом, перенарезал партиции, чтобы /tmp и /var были на отдельных партициях, поправил соответственно fstab.
После примерно суток работы в read only упала патриция, примонтированная к /var, но уже не с плохими контрольными суммами inode, а с Free blocks count wrong

На работоспособность это влияет частично, вот прямо сейчас пишу с /var read only,
но хотелось бы понимать причины и решение проблемы.

Щас перезагружуcь, передвину партицию /var поближе к началу диска, посмотрю, что будет.

Кто-то может подсказать, что с этим делать?

[ecc83]

Кто-то может подсказать, что с этим делать?

Есть возможность попробовать с другим ядром?

[AlexanderL]

Было ядро 4.19.5, проблема началась примерно на 4.19.2, не помню точно, ядра менял, надеясь, что проблема уйдёт.

Up: timeshift с ядром 4.18.16 отработал нормально. Никакие партиции пока никуда не двигал, всё как было при предыдущем падении.

[EvangelionDeath]

AlexanderL, о. Это что-то в 4.19 намутили. В нем проблемы и с BTRFS (данные получены из надежных источников, не могу не доверять, но и подробностей не знаю). Так что возможна проблема не в реальной ФС, а в реализации VFS ядра.

https://www.phoronix.com/scan.php?page=news_item&px=EXT4-Linux-4.19-Corruption

Не, таки в ядре реализации ФС они поломали...

[AlexanderL]

Это что-то в 4.19 намутили. В нем проблемы и с BTRFS

Спасибо. Следующий шаг в планах как раз был перейти на BTRFS...
ТС, как видно по состоянию на 12/02/2020 потерял интерес к созданной им теме (пометка Решено в теме отсутствует, тема оставлена не закрытой, сообщений в теме давно не было). Тема стародавняя (последнее сообщение в топике: 07/12/2018; последнее сообщение от ТС в топике: 03/12/2018). Модератором раздела принято решение закрыть тему.
--zg_nico

[prid]

Сталкиваюсь с этой фигней уже 4ый раз за 2 недели - с тех пор как купил SSD Samsung 860 EVO и обновил ядро на 4.19, ибо до этого у Samsung SSD 8** были терки с TRIM, коих на 860 серии быть не должно, но он попадал под регулярку блеклиста в предыдущих ядрах. Сегодня уже был намерен написать в Samsung как вот попал на эту ветку(спасибо участникам). Фикс, вроде как, должен выйти в 4.19.8: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-4.20-BLK-MQ-Fix.
Ждем-с

[DimanBG]

prid, Disks on Linux 4.19+ were only vulnerable if using BLK-MQ and using no I/O scheduler.
Ты используешь BLK-MQ?
В 4.19 - В EXT4 в поля суперблока добавлена поддержка 64-разрядных счётчиков времени, что позволит решить проблему с переполнением 32-разрядного счётчика в 2038 году;
Больше ничего нового с EXT4 в 4.19 не наблюдается. Счетчик виноват?
А вот в 4.18 - В файловой системе ext4 продолжена работа по чистке кода и повышению надёжности работы в условиях обработки некорректных образов ФС, специально модифицированных для вредоносных целей.

Так что возможна проблема не в реальной ФС, а в реализации VFS ядра.

Вот это ближе.
И не забывайте, что баги не только с самой ФС или ядром, там много пишут на каждый чих и пук, аварийное выключение - баг с ФС, к диску пушной зверёк на ПМЖ пришел - баг ФС. У кого-то самосборные ядра. Какая кривизна рук или просто ошибка при конфигурировании - никто не знает - баг ФС. Если всю муть убрать, то реально проблема есть, но появляется при сочетании нескольких факторов.     
 

Кто-то может подсказать, что с этим делать?

Ну, при твоих задачах, попробуй полностью справедливую очередь. Увеличь дисковый кеш.

[Morisson]

Ты используешь BLK-MQ?

А оно там не по-умолчанию?
Это планировщик процессов, а не ввода/вывода

[Morisson]

Чтобы такой фигни не было- нужно явно указать i/o sheduler

Код: [Выделить]

sudo nano /etc/udev/rules.d/60-iosheduler.rules
Туда

Код: [Выделить]

# set scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*|nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq-mq"Сохраняем (Ctrl+X -> Y -> Enter)
Применяем правила на ходу

Код: [Выделить]

sudo udevadm control --reload && sudo udevadm triggerили просто перезагружаемся.

[БТР]

http://www.opennet.ru/opennews/art.shtml?num=49720