LINUX.ORG.RU

Баг в ядре уничтожает файлы

 , , ,


0

3

Видимо, вот этот. Сейчас в арче 4.19.27-1 это LTS, так вот сразу после обновления c предыдущего LTS возникли проблемы с I/O и при первом ребуте fsck похерил кучу файлов, включая пакеты. Причём бинарники ведь явно только читаются, в отличие от всякого кэша (почему-то пострадал в основном он). Также пострадал электрон и один файл из проекта (был открыт atom). Проблема повторилась несколько раз.

В LTS ядро не завезли фиксы, или я нарвался на что-то новое? В предыдущем LTS 4.16 такого не было, SSD работает без нареканий и в смарте ничего подозрительного. Вроде как уже в 4.19.8 должны были пофиксить, разве нет?

★★★★

Ответ на: комментарий от InterVi

Отрубает queued TRIM.

The data corruption has been confirmed on the Linux operating system (the only OS with queued trim support as of July 1, 2015).

Получается, другие OS вообще не использовали этот queued trim по крайней мере до июля 2015.

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 3)
Ответ на: комментарий от greenman

Попробую вместе с отключением blk-mq, но не знаю когда. Пока что не хочется снова просрать файлы.

InterVi ★★★★
() автор топика
Ответ на: комментарий от greenman

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

В верхнем ценовом сегменте (где NVME) у них порядок, вполне конкурируют с WD Black и Intel 760p (от этих они мало отличаются, платформа-то одна и та же).

anonymous
()
Ответ на: комментарий от greenman

из интересного нашёл вот это

мар 06 21:26:13 archlinux kernel: EXT4-fs error (device sda2): ext4_lookup:1574: inode #7471645: comm Cache2 I/O: iget: bad extra_isize 30773 (inode size 256)
мар 07 13:57:28 archlinux kernel: EXT4-fs error (device sda2): ext4_lookup:1574: inode #5507200: comm systemd-timesyn: iget: bad extra_isize 21960 (inode size 256)
мар 07 13:57:28 archlinux kernel: EXT4-fs error (device sda2): ext4_lookup:1574: inode #5507200: comm sd-resolve: iget: bad extra_isize 21960 (inode size 256)

весь ядерный лог https://yadi.sk/d/FICXPcXFTfjJAA

смарт https://pastebin.com/UjBVXi9d

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

InterVi ★★★★
() автор топика
8 августа 2019 г.
Ответ на: комментарий от greenman

Дней 5 интенсивно использую комп, проблемы нет. В параметрах ядра:

GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=0 libata.force=noncqtrim"
Первый на случай LTS ядра. Но я пока на 5.2.6-arch1-1-ARCH, а разделы диска в LVM. Не знаю что конкретно пофиксило проблему и проверять не хочется.

По-хорошему надо бы зарепортить баг.

InterVi ★★★★
() автор топика
Ответ на: комментарий от InterVi

UPD: баг всё-таки проявился и превратил в прах корневой раздел. Хомяк не пострадал (пока), потому что был зашифрован (по умолчанию TRIM выключен для шифрованных томов). Теперь использовал btrfs для корня, вместо ext4. Несколько раз вызывал команду fstrim, пока всё нормально.

InterVi ★★★★
() автор топика

Чё, какие новости? Мне стоит уже переживать или исправили? Discard включен, mq включен, ext4.

anonymous
()
Ответ на: комментарий от anonymous

А вот ntfs у меня рассыпалась, какие-то неудаляемые файлы и каталоги опять. Брр.

anonymous
()

Арч стабильная уничтожаемость фаилов ) Убунту спасение от маргиналов которые ещё смеют советовать арч в котором верхом стабильности считается повреждение ФС из ща ядра , но каникулы кончаются , а каноникал нет.

anonymous
()
Ответ на: комментарий от InterVi

баг всё-таки проявился

Так че за баг? Может у тебя оборудование глючит и так совпало. И ты думаешь, что это софтварные проблемы.

anonymous
()
Ответ на: комментарий от anonymous

Делал установку из под дебиана, там тоже проявлялся этот баг. Убунта основана на дебиане, так что наверняка там тоже самое.

InterVi ★★★★
() автор топика
Ответ на: комментарий от greenman

У меня побыстрее и раза в 2 дороже по-моему. Ну и млц. А в отзывах что-то говорят эти ADATA очень проблемные, и ведь они не такие уж и дешёвые. Кто их покупает?

anonymous
()
Ответ на: комментарий от InterVi

UPD 2: btrfs оказался надёжней, при повреждениях блокируется запись, хотя фс смонтирована как rw. Но btrfs-fsck убил её в хлам, раздел перестал распознаваться. Теперь живу совсем без TRIM, что не очень хорошо.

Гугл говорит, что такая проблема всплывала на серверах с нормальными SSD. Вот такой надёжный линукс.

InterVi ★★★★
() автор топика

5.2.9 нету такой проблемы, скорее железо

beeen007
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.