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

Видимо, вот этот.

А шедулер какой? Если не none, то точно не этот баг. К тому же, да, его уже должны были давно пофиксить.

cat /sys/block/sda/queue/scheduler

Тогда это какой-то другой баг, тот срабатывал без планировщика (none). Откати ядро пока, чтобы убедиться, что проблема именно в новом ядре.

Ну или можешь выключить blk-mq. Может, проблема в нем.

scsi_mod.use_blk_mq=0

В параметры ядра.

Сейчас на 5.0, но пока рано делать выводы. Такое уже было, и в тот раз я просто перешёл на LTS, бывший тогда 4.16.

По-моему, проблема хардварная (ssd/шлейф/питание/etc)

и почему же она проявляется только на 4.19?

Лет 5 юзаю без проблем, как вызвать баг? А хотя у меня более старая версия. Туда портировали?

А ты проверял это же железо с другими версиями ядра после возникновения проблемы (включая предыдущую)?

В тот раз откатился на 4.16, проблема исчезла. Про 5.0 пока не могу сказать, мало времени прошло.

Бле, хорошо, что у меня btrfs. Хотя ext4 вроде в каждом андроиде и бюджетном NAS, всегда ей немного не доверял.

Да уж, хорошая шутка. А проблема точно в ext4? Такая подстава — самая надёжная и безопасная фс всех времён просирает файлы (при каких условиях?).

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

шутка

А ты посмотри, что сейчас в топовых Synology и QNAP :) Ну и если btrfs навернётся, то шумно и весело, а не запортачит по-тихому файлы, в которых ты обнаружишь повреждение когда оно уже год будет как во всех резервных копиях. Стоит задуматься.

Такая подстава — самая надёжная и безопасная фс всех времён просирает файлы

Про неё это периодически ещё со времён ext4dev слышу. Лично у меня вроде ничего не пропадало, хотя до сих пор подозреваю, что на ext3 однажды пропал целый каталог без всяких ошибок.

попрошу не использовать в одной строке теги arch kernel ext4

ну я то не знаю, мб как раз в арче понаписали патчей

Вот да, только что заметил что пропал день моей работы. В файлах просто каша. А сохранялись они нормально, без ошибок, и в fsck не всплывали.

Странно. Сижу на 4.19 LTS, Arch. ПРоблем нет. Я присоединяюсь к проверке оборудования.

какими утилитами погонять, кроме fsck и e2fsck?

Убери из опций монтирования discard.

Вместо этого – fstrim по таймеру.

с екст4 точно все в порядке, более 5 лет сижу без форматирования на 4 жестких дисках

у меня похожее было с SSD, но там был оффициальный баг в прошивке и через месяц пофиксили(обновить прошивку пришлось вручную)

также видел такое при «установке линукса/винды» на чистый диск на новой материнке(пару месяцев назад вышедшей от даты покупки), но там тоже был баг в прошивке(УЕФИ) и через неделю вышла новая прошивка и все работало

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

Вот такое можно найти ADATA Ultimate SU650 + archlinux = проблемы.

ADATA

Зато недорого 😂

Память. Проверяйте память.

Да-а-а

На сегодня под крышками ADATA SU650/SU655 встречаются не только контроллеры SMI2258XT с микросхемами разных типов и производителей (3D TLC/3D MLC), не только контроллер Marvell 88NV1120 (с 3D TLC), но и устройства на основе контроллера Maxiotek (по сути, пермаркированные ADATA SU700) и устройства на основе контроллера Realtek (вообще ранее не замеченные в самостоятельно существующей моделью). Не думаю, что в компании ADATA разбираются в иерархии модельного ряда, скорее всего просто пихают совершенно произвольные партии начинки в совершенно произвольные корпуса.

Это проверка файловой системы, а тебе надо железо проверить. Я могу ошибаться, но было всё для проверки, что на загрузочном диске Rescue CD http://www.system-rescue-cd.org/

Это решает только проблемы с тормозами TRIM. То есть если TRIM что-то портит, то не имеет значения, как его запускать.

Насколько я понимаю, иногда проблемы приносит queued TRIM. Не знаю, будет ли он задействован при fstrim. Для ряда моделей ssd (даже для именитых Samsung) в ядре есть blacklist, отключающий queued TRIM. Судя по чехарде начинки ssd ADATA, для них такой blacklist создать проблематично.

Насколько я понимаю, иногда проблемы приносит queued TRIM

Да.

Не знаю, будет ли он задействован при fstrim

Будет, если я правильно понимаю логику в коде ядра.

Судя по чехарде начинки ssd ADATA, для них такой blacklist создать проблематично.

Ну почему, нужно только репортить баги или слать готовые патчи к списку. Но во времена, когда Intel 660p с NVMe стоит дешевле многих SATA SSD, лучше не экономить на спичках и не поддерживать производителей с низкой социальной ответственностью :)

Будет

Ну с поправкой на чёрный список, то есть реализация одна в ядре, от способа вызова не зависит. Уровнем выше ещё находятся ФС-специфичные обёртки.

Попробуй добавить libata.force=noncqtrim в параметры загрузки ядра.

Прогнал двумя селф-тестами, чисто. И оперативку мемтестом, тоже чисто. А на том диске вроде ничего особенного.

Может ли возникнуть такая проблема, если TRIM начинается прямо перед выключением и в результате прерывается не корректно?

Оперативку надо гонять пару суток. В смарте только лонгтест отображает проблемы, достаточно 1 раза.

Это кажется маловероятным, но контроллер может сойти с ума по самым разным причинам (скажем из-за проблем с питанием вполне).

на 5.0 проблема всё-таки проявилась

Лонгтест и делал. А чем ещё оперативку гонять, кроме мемтеста?

Очень уж напрягает, что проблемы возникают именно на новых ядрах и откат на 4.14 (да, я ошибся, предыдущим LTS был 4.14, а не 4.16) уже один раз помогал. Сейчас снова откатился, посмотрим что будет.

если TRIM начинается прямо перед выключением

ВЫключи эти настройки!

Сорян, долго доходила проблема. Сейчас в нормальных железках этим занимается контроллер (в моём случае точно, я много рыл в направлении) и никаких настроек не нужно!

Сейчас снова откатился, посмотрим что будет.

Проблема не в ядре (уже бы чинили).

Проблема железа. На малинке обновил ядро до 4.19 и ничего не похерилось после fsck на флешке за 300 рублей с ext4.

Попробуй сначала 5.0, если так же, то сиди на 4.14 и жди, поддерживать еще долго будут.

Возможно что-то поломали конкретно для твоего SSD. Кроме малинки нигде ext4 нет, так что говорить точно не могу.

А вообще я адепт btrfs :P

А CPU какой? Что-то я на стареньком Athlon-e словил пару глухих зависаний с этим 4.19.27

Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz

Вай фай от интеля на борту есть?

Ralink corp. RT3290 Wireless 802.11n 1T/1R PCIe

Таки проблема в ядре. Комп интенсивно используется несколько дней и всё нормально.

[root@archlinux alex]# uname -a
Linux archlinux 4.14.90-1-lts #1 SMP Fri Dec 21 15:53:10 CET 2018 x86_64 GNU/Linux
[root@archlinux alex]# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq 

Ну и нахрена? 14 же не подвержена

Я не смогу оставаться на нём вечно. Надо чинить.

Ты пробовал libata.force=noncqtrim с ядром 4.19?

это отрубает TRIM или что?