LINUX.ORG.RU
ФорумTalks

Ядро 4.19.x может вызывать серьёзные ошибки и потерю данных на файловой системе ext4

 , , , ,


0

4

Только у части пользователей - увы, причина до сих пор не установлена, bisect не находит проблемный коммит.

https://bugzilla.kernel.org/show_bug.cgi?id=201685

P.S. Не могу добавить теги: «data loss», «data integrity».

Вообще всеравно.

[PtiCa@black-ws tmp]$ uname -a
Linux espws 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Любители накатывать master должны страдать. С тем энтузиазмом, как Линус гонит версии, последний стейбл равносилен master ветке.

Довольно характерно, кстати, в багтрекере. Разработчик ФС пишет.

I'm using a 4.19.0 based kernel (with some ext4 patches for the 4.20 mainline) and I'm not noticing any file system problems. I'm running a Dell XPS 13 with an NVME SSD, and Debian testing as my userspace.

Где ссылки на интеграционные и стресс- тесты? Где последующее добавление теста на пофикшенный баг? Где отчеты по тестам предыдущих версий? Это линукс. Миллиарды долларов инвестируются на то, что бы в багтрекеры говорили: «УМВР»

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

Где ссылки на интеграционные и стресс- тесты?

У вендоров. Платишь денюшку, а они тестируют нужный конфиг ядра на нужном железе.

snizovtsev ★★★★★
()

Эпично! Сижу на 4.19.4, прям даже интересно стало.

StReLoK ☆☆
()

Есть кое-где такое ядро... А если используется ФС ext3 через подсистему ext4, встречаются проблемы?

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

Ага, весело. Только это не денежка. А инвестиции. О денежках можно было бы говорить, если бы покупка какого-нибудь rhel или бубунты обеспечивала гарантию его работы на сколько нибудь адекватном списке ноутбуков, например. Сейчас же даже покупка ноута с предустановленной бубунтой не дает гарантий работы блютуза или сканера отпечатков.

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

я не сказал что бесплатно

На system76 думаю всё работает, даже ME отключают.

т.е. сабжевая проблема там будет точно отсутствовать?

Deleted
()

Странно, ext4 разработали больше десяти лет назад, а оно ломается.

bbk123 ★★★★★
()

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

gag ★★★★★
()

Хм, мне тут на днях как раз с 4.19 ядром впервые система потребовала fsck-нуть корень при загрузке.

Перезагружусь-ка я на стоковое от греха подальше.

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

покупка ноута с предустановленной бубунтой не дает гарантий работы блютуза или сканера отпечатков

Да это мелочи, я как-то купил Dell с бубунтой, там WiFi не работал и 2/3 памяти не виделось (32 разрядный дистр поставили без PAE). А, ещё веб-камера не пахала. Блютуз даже не проверял, снёс к чертям и заменил на Debian.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от Deleted

Любители накатывать master должны страдать.

И им за это нужно быть благодарным. Иначе страдало бы значительно больше народа.

Где ссылки на интеграционные и стресс- тесты?

Дальше он пишет:

The reason why I ask is because I've run gce-xfstests on 4.19, 4.19.1, and 4.19.2, and it uses LVM (nothing fancy just standard LVM volumes, although xfstests will layer some dm-error and dm-thin on top of the LVM volumes for specific xfstests) on top of virtio-scsi on top of Google Compute Engine's Persistent Disks, and I'm not noticing any problems.

Но, оказывается:

I just noticed that my .config file for my GCE testing has CONFIG_SCSI_MQ_DEFAULT set to «no», which means I'm not using the new block-mq data path.

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

Иначе страдало бы значительно больше народа

just noticed that my .config file for my GCE testing has CONFIG_SCSI_MQ_DEFAULT set to «no», which means I'm not using the new block-mq data path.

И это подтверждает мой тезис о том, что с инфраструктурой беда - никакой автоматизации тестирования абсолютно. Все построено на том, что какой-нибудь васян скомпилирует мастер и запустит на рандомном железе

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Ну есть инициатива https://kernelci.org/ , но там вроде больше про загружабельность разных плат. Я так понимаю upsteram ядро не воспринимается как «продукт», а является просто точкой синхронизации разных команд. Тесты могут и быть, но хостятся не на единой инфраструктуре ядра и его коммитах, а на форках ядра в рамках

  • Проекта (фс, netfilter, mesa, etc)
  • Компании-дистрибутива (RHEL, Ubuntu, Android)
  • Производителя железки (Intel, IBM etc)

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

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

InterVi ★★★★★
()

У меня например саспенд на этом ведре сломался. Засыпает, но как-то долго, а когда просыпается — жуткое слайдшоу 1 fps секунд в 5, при это процессор и память не загружены совершенно. Откатился на 4.14 — все норм.

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

Ну рач например.

$ pacman -Si linux                                                                                                         
Repository      : core
Name            : linux
Version         : 4.19.4.arch1-1
Description     : The Linux kernel and modules
Architecture    : x86_64
URL             : https://git.archlinux.org/linux.git/log/?h=v4.19.4-arch1
Licenses        : GPL2
Groups          : base
Provides        : None
Depends On      : coreutils  linux-firmware  kmod  mkinitcpio
Optional Deps   : crda: to set the correct wireless channels of your country
Conflicts With  : None
Replaces        : None
Download Size   : 66.89 MiB
Installed Size  : 71.31 MiB
Packager        : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Build Date      : Fri 23 Nov 2018 15:05:48 +06
Validated By    : MD5 Sum  SHA-256 Sum  Signature
Im_not_a_robot ★★★★★
()

Да это што. Я тут файловую систему f2fs попробовал на трех разных SSD. И что вы хотели, она посыпалась на всех трех.

steemandlinux ★★★★★
()

$ mount | grep -c type\ ext
0
Прям как чуял чем-то :)
А про zfs ничего плохого не слышно?

imul ★★★★★
()

Начиная с декабря 2017, ядро повреждает примонтированные ext4 при наличии трафика через wifi или bt. Скорее всего, оттуда же растёт. Забей, никому не интересно, мы все умрём.

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

Начиная с декабря 2017, ядро повреждает примонтированные ext4 при наличии трафика через wifi или bt. Скорее всего, оттуда же растёт.

Кстати, после того как я отключил всё энергосбережение, что касалось дисков и SATA, проблема возникать стала реже. Может совпадение, хз...

Deleted
()

я пока не наблюдаю проблем с ФС. я только недавно винт поменяла в ноуте: старый полетел внезапно с кучей бэдов. но это был хардварный глюк.сейчас на 4.19 сижу, 4.20 некогда пока собирать было. но я восстанавливаю данные с глючного диска потихоньку и за последние дни перекомпилила дофига софта для обновления всего ПО на компе. вроде пока никаких проблем с ext4 не замечала.

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

на некоторых чипсетах в биосе есть опции для отключения влияния блютуса на вайфай. там как-то не всё чисто с хардом. чую жопой, что там какой-нибудь баг не слабее мелтдауна может вылезти, если начать копать в сторону всяких чипов для материнок:)

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

не дает гарантий работы блютуза -На system76 думаю всё работает

да так же всё отваливается-чинится-отваливается-чиится с апдейтами ядра

fornlr ★★★★★
()
# uname -a
Linux seh_desktop 4.19.4


заголовок звучит как вызов

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

Что плохо, так это то, что 4.18 слишком быстро объявили EOL. Вышла новая порция стабильных обновлений, но или для 4.14, или 4.19.

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

Собрать инфраструктуру бывает не так-то просто:

This bug is a really scary one, both because of how the severity of its consequences, *and* because neither of us can reproduce it on our own systems or regression tests --- so we are utterly reliant on those people who *can* reproduce the issue to give us data. We very much want to make sure this gets fixed ASAP!

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

Вполне возможно, что проблема затрагивает не только ext4

Желающие могут проверить. Нужно ядро 4.19.x c CONFIG_SCSI_MQ_DEFAULT=y и /sys/block/sd*/queue/scheduler [none]. Запустить скрипт. За потерю всех данных с меня не спрашивать.

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

Я когда-то fsck-ал систему, она рапортовала, мол, всё пучком. И всё, вроде, работало. Вот только личные файлы на хомяке начали таять. Вроде все файлы на месте, а открываешь - там пол картинки, тут запоротый файл, там ещё что-то. Проверяй все файлы теперь.

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

Странно, 2 недели назад упомянули разработчика Ming Lei из Red Hat, причастного к изменениям, которые, возможно, провоцируют эту ошибку, но он так и не присоединился к дискуссии в этом баг-репорте. А потом начал сопротивляться уже посланному патчу.

Если кто-то так безответственно работает (не обращает внимание на обратную связь, затрагивающую внесённые им изменения), может, его надо отстранить... Хотя, может, это политика Red Hat: сделать, чтобы у всех бились данные, но только не у клиентов Red Hat, т.к. Red Hat его публично доступную версию изменений и не использовали. А сопротивляется он потому, что правильное решение у него (и Red Hat) уже давно есть, и выглядит оно по-другому, а этот Jens Axboe, как назло, уже нашёл простой способ обойти проблему.

И ещё не заметил в патче https://patchwork.kernel.org/patch/10712695/ полей «Reported-by», хотя к человеку, открывшему отчёт, присоединились ещё несколько людей.

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

А уже 29-го августа предлагали вообще откатить этот злополучный патч «blk-mq: issue directly if hw queue isn't busy in case of 'none'» https://lkml.org/lkml/2018/8/28/689, которому Jens Axboe, оказывается, изначально дал добро.

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

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

meliafaro ★★★★★
()

О!

А мне вот не верили когда я про затирание загрузчика на ext4 писал. :)))

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от post-factum

Конечно. Но, если он не присоединился к дискуссии, значит, считает, что у всех кроме него. (Ну или по вышеописанной причине теории заговора.)

gag ★★★★★
()
Последнее исправление: gag (всего исправлений: 1)
Ответ на: комментарий от post-factum

То, что Red Hat борется с конкурентами (Oracle) недружественными squashed патчами, мы уже давно знаем. Может, о новых методах мы просто пока достоверно не знаем (а они уже в ходу).

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