Повреждение данных в Ext4 под ядрами в ветке LTS-версий 6.1.X.

Пишут из за этого откладывается выход Debian 12.3 хм.

Запускаю у себя apt update, и вижу:

N: Репозиторий «http://deb.debian.org/debian bookworm InRelease» изменил значение поля «Version» с «12.2» на «12.4»

Прикольно в Debian-е то ;)

У меня Debian testing стоит... вчера не читая произвёл обнову, хотя краем глаза видел что как минимум репозитории в яндексе поменяли индексы на хз какие. Надеюсь всё устаканилось, и я проскочил удачно).

да я гляжу:

apt list --upgradable | grep linux

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-image-amd64/stable 6.1.66-1 amd64 [может быть обновлён с: 6xxx]
linux-libc-dev/stable 6.1.66-1 amd64 [может быть обновлён с: 6xxx]

Но меня интересует другое, что разве пропуск минорного релиза, так можно было ? Наверное у них с этой ошибкой полный косяк вышел …

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

Как хорошо что у меня ядро из бэкпортов

6.5 где этот баг нативный а не внесённый?

Ой, подумал что в нем уже пофиксили :)

А хотя в нём кажется бага и не было, всё норм. Баг появился именно при переносе.

Пишут из за этого откладывается выход Debian 12.3 хм.

Сформировано корректирующее обновление дистрибутива Debian 12.4

opennet

Прикольно, я своим apt update, узнал о выходе нового релиза ;) Раньше новостей.

Аналогично.

Уже 2 дня обсуждается: Ext4 гробит данные (в том числе в Debian Stable).

Нет, прикинь, у меня вчера была версия реп 12.3 на ftp debian и yandex. А сегодня они поменялись на 12.4, буквально увидел 15 минут назад. Так что вообще бардак...

Уже 2 дня обсуждается: Ext4 гробит данные (в том числе в Debian Stable).

А реально он у кого-то здесь угробил данные? Или проблема всё же экзотическая? Вроде, как минимум, с O_DIRECT связана, то есть, не прям уж так, что всем кирдык?

Капец

А еще F2FS как была сломана в 5.18 так и остаётся, хотя бесконечный цикл и краш треда как-то починили (теперь GC тупо вообще не работает лол)

В каких версиях ядра 6.1 этого бага нет?

6.1.66 (почему у дебианщиков эта версия называется 6.1.0-15)

6.6.6 привет от Грега! ))

жесть какая, в нтфс было такое? Пусть и линукс но файлопомойка у меня на нтфс лежит все таки.

Смачно так лососнули тунца диванные эксперды, доказывавшие что ничего лучше ext4 на свете нету, что btrfs/zfs кал и «не нужно». Но это все еще не так эпично как убийство ntfs обращением к несуществующему файлу с магическим именем

6.1.63

https://github.com/shubham0d/CVE-2021-28312

zfs

https://www.opennet.ru/opennews/art.shtml?num=60212

Shit happens.

Shit happens.

Но именно ext4 выбирают из-за мифа о её надежности, а других причин использовать её нет. Рассчитывать на отсутствие багов в fs всегда не лучшая затея.

Но именно ext4 выбирают из-за мифа о её надежности, а других причин использовать её нет

Проще реализация → меньше риск нарваться на проблемы, очевидно же. Если всякие там сжатия со снимками на уровне ФС и проч. не нужны, то и btrfs и ко тоже не сильно нужны.

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

Так что это не миф.

доказывавшие что ничего лучше ext4 на свете нету

Конечно нету. А ещё нет ничего лучше роллинг-релизных дистрибутивов. Топик в очередной раз показал, что debian-style «стабильность» это тупое говно тупого говна.

Проще реализация → меньше риск нарваться на проблемы, очевидно же.

Меньше риск нарваться на проблему в реализации. Но в ext4 нет контрольных сумм для данных и там проблемы «by design».

Если всякие там сжатия со снимками на уровне ФС и проч. не нужны, то и btrfs и ко тоже не сильно нужны.

Угу, для этих случаев отлично подходит xfs. Там хоть рефлинки есть, которые используются автоматически. Фишек btrfs там нет, зато быстрая как ext4.

А ещё нет ничего лучше роллинг-релизных дистрибутивов. Топик в очередной раз показал, что debian-style «стабильность» это тупое говно тупого говна.

Разумеется, ведь иметь сломанное ядро и терять данные почти 2 недели намного лучше, чем полдня.

Но в ext4 нет контрольных сумм для данных

Если всякие там сжатия со снимками на уровне ФС и проч. не нужны

Так-то можно и dm-integrity задействовать при желании.

Угу, для этих случаев отлично подходит xfs.

Если бы умела в уменьшение раздела, то цены бы ей не было.

Так-то можно и dm-integrity задействовать при желании.

Что увеличивает сложность и накладные расходы. Не знаю как на ssd, на hdd быстрая xfs показывала результаты в несколько раз медленнее zfs/btrfs после этого.

Сижу на ветке 4.19(gentoo), повреждений не заметил.

Не знаю как на ssd, на hdd быстрая xfs показывала результаты в несколько раз медленнее zfs/btrfs после этого.

А какой режим использовался? Если умолчальный journal, то конечно будет медленнее: данные пишутся сначала в журнал, а потом куда нужно, т.е. дважды. В режиме bitmap производительность должна проседать незначительно.

А какой режим использовался?

journal. Но лучше не ломать голову и использовать zfs/btrfs.

Из личного опыта ни разу не терял данные на ext4. А вот в zfs на FreeNAS было после отключения электричества. Я потом не смог тупо примонтировать том из-за возникновении ошибки. Честно, даже разбираться не стал, и вместо фряхи воткнул обычный деб с обычной самбой на ext4. Кстати, работает уже как минимум 4 года в режиме нонстопа.

Зачем снапшоты на файлопомойке? И zfs - это не родное, инопланетное, даже /etc/fstab редактировать не надо. Сейчас хотя бы специальное ядро для нее не нужно. А вообще забавно, что тут в укор ей ссылку кинули, мол cp-пейсатели что-то там накосячили и ломали данную файловую систему

Из личного опыта ни разу не терял данные на ext4.

Я раза три сидел с debugfs, один раз писал expect скрипт для fsck в попытках запустить фс в меняемый срок. При простой потере питания. Чаще всего сталкиваюсь с проблемами ext4, но она и чаще всего встречается на железках.

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

А вообще забавно, что тут в укор ей ссылку кинули, мол cp-пейсатели что-то там накосячили и ломали данную файловую систему

Там просто баг в fs, который со старой cp был не заметен, так как она не использовала затрагиваемые функции. А coreutils 9.x мастхэв для пользователей btrfs/xfs и свежих версий zfs, CoW при копировании по умолчанию - один из поводов быстрее свалить с ext4.

В zfs пару месяцев назад появилась поддержка рефлинков, возможно она стала пригодной для десктопов.

CoW при копировании по умолчанию - один из поводов быстрее свалить с ext4.

Какая наивность. Я могу поинтересоваться что позволяет вам делать столь громкие заявления и выпады в сторону ext4 (при всёх её недостатках)?

Я могу поинтересоваться что позволяет вам делать столь громкие заявления и выпады в сторону ext4 (при всёх её недостатках)?

Какие выпады? Ext4 редко когда имеет смысл использовать на типичном сервере/десктопе, она просто устарела.

Ext4 редко когда имеет смысл использовать на типичном сервере/десктопе, она просто устарела.

В силу многих причин - она надёжна как валенок. «Мамой клянусь».

Не, там идёт посыл такой, что весь функционал уже написан и код особо не шатают, поэтому она надёжна и всё в таком духе. Хотя, как мы видим из новости, Shit действительно иногда happens.

Лично я считаю, что:

1. Любой код содержит ошибки.
2. Если программа работает без ошибок, то это не означает, что их в ней нет.

Исходя из этого есть смысл выбирать фс в зависимости от необходимого функционала, а «компромат» в сети можно нарыть на любую фс.

В силу многих причин - она надёжна как валенок. «Мамой клянусь».

В первом сообщении и написал, что её выбирают по одной причине - необоснованная вера в мифическую надежность.

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

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

необоснованная вера в мифическую надежность.

Всё просто: (1) сколько терабайт вы пишите в день, (2) каков общий объём storage? Я предлагаю пиписьками не меряться. Да.

Дома ~50tb объем, в день 2-3tb на запись. По работе раз в 10-20 больше. Не большие объемы, но проблем с ext4 хватает.

Дома ~50tb объем, в день 2-3tb на запись. По работе

OPRA - это примерно 30GBit в пике и ~10Gbit после всех сглаживаний. Откуда такие объемы в домашних условиях? Я думаю - вы тупо врёте.

hdd - 5x8Tb, 16Tb, 2x4Tb hdd. Тут скачиваются/раздаются разного рода торренты и зеркала. Сейчас xfs. 5x1 tb, 2x2 tb nvme sdd. Тут разная солянка, по большей части типичные десктопные вещи на разных машинах. Btrfs. 2x1 tb, 2x3 tb hdd + 2x2 tb sdd. Proxmox с виртуалками, zfs. Один диск под видео наблюдение в xfs. Плюс по мелочи hdd-шники на 1-3 tb для временного хранения. Про них вспоминаю редко, там ext4 осталась.

Считать точные значения мне лень. Нагрузка больше на чтение, но 2-3 tb записи в день есть.

но 2-3 tb записи в день есть.

Ха. Да.

Фанбои чего угодно - те ещё фантазёры

Ха. Да.

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