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

[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.

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

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

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

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

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

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

Гарантии и бесплатно - выбери одно. На system76 думаю всё работает, даже ME отключают.

А кто говорит о гарантии (кроме тебя)? Вроде речь была о здравом процессе разработки.

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

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

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

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

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

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

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

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

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

Любители накатывать 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.

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

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.

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

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

• Проекта (фс, netfilter, mesa, etc)
  
• Компании-дистрибутива (RHEL, Ubuntu, Android)
  
• Производителя железки (Intel, IBM etc)
  
  Подозреваю, что большинство из них не выкладывают свой тестсьют в публичный доступ, чтобы иметь преимущество по оказанию платной поддержки.

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

А какая мотивация у любителей самое свежее ведро накатывать?

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

А какая мотивация у любителей самое свежее ведро накатывать?

Оно дефолтное в дистрибутиве например.

Это в котором?

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

$ 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

Ну так вам, тестерам всея опесорца, на роллингах страдать и положено.

Ну так-то стабильный он, иногда вот только конфузы.

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

Шляпа не зря ушла на XFS

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

Хм, у меня как раз /home на ней. Какие альтернативы для хомяковой файлопомойки?

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

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

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

Очевидный XFS.

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

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

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

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

# uname -a
Linux seh_desktop 4.19.4

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

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

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

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!

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

Проблема локализована. Jens Axboe написал патч.

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

It's Looking Like The EXT4 Corruption Issue On Linux 4.19 Is Caused By BLK-MQ

И сидит на 3.10 :)

Btrfs

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

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

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

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

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

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

А уже 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, оказывается, изначально дал добро.

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

Ming — большая няшка, а ошибки бывают у всех.

О!

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

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

Ты тоже недалеко от теории заговора уходишь.

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