Ext4 гробит данные (в том числе в Debian Stable)

Это уже виляния жопой.

Ну так не виляй ей.

Почему результат должен быть другой?

Потому что дефекты дизайна ФС могут проявляться в зависимости от кучи условий. Например, фрагментации ФС. С чистой ФС, у которой фрагментация по нулям, всё будет работать, а с пожившей пару лет и накопившей говна – нет. И так далее.

Да посрать. За неделю с лишним куча народа успела обновиться.

Кстати, это ядро же не только в Debian есть.

Судя по https://gitlab.archlinux.org/archlinux/packaging/packages/linux-lts/-/commits/main , те же пользователи Arch, кто сидит на linux-lts, могли насладиться этой проблемой в течение полутора недель.

Да посрать. За неделю с лишним куча народа успела обновиться.

Кстати, это ядро же не только в Debian есть.

Судя поhttps://gitlab.archlinux.org/archlinux/packaging/packages/linux-lts/-/commits/main, те же пользователи Arch,кто сидит на linux-lts, могли насладиться этой проблемой в течение полутора недель.

▲ ~ uname -a
Linux tempest 6.1.63-xanmod1 #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan  1 00:00:00 UTC 1980 x86_64 GNU/Linux

Слава тапкам я не успел обновить ноутбук :DDDD

С другой стороны, тут на ext4 только /boot, поэтому не особо страшно.

Ну так не виляй ей.

Скрипт предложил ты. Изначально ничего про размер и фрагментированность ты не говорил. Когда твои предположения провалились, то начал придумывать постфактум новые условия. Если я прогоню на старой ФС и ничего не поймаю, то ты ещё что-нибудь придумаешь. Кейс про дурака и тысячу мудрецов.

Давай заранее озвучь все условия проявления твоих мифических дефектов дизайна ФС, чтобы не осталось места для манёвров жопы.

Кто тебе сказал что он не шатает ext3?

Тогда это тупость и нарушение posix, для каждого должен быть разный драйвер, чтобы не шатать стабильное.

multi-device в btrfs — это не stripe.

У меня raid1 для метаданных и raid0 для данных. Это как раз strip насколько я понял. Без стрипа будет режим single.

raid0 для данных

А, ок.

Почему btrfs так не может-то

Не знаю, кто тебе это сказал, но вообще-то может.

Тогда это тупость и нарушение posix, для каждого должен быть разный драйвер, чтобы не шатать стабильное.

Ээээ… што? Причём тут POSIX вообще?

Но к слову, если ты реально не в курсе, ext2/3/4 – это на самом деле одна и та же ФС, просто в последующих версиях больше фишек сверху накручено. TL;DR ext2 – подмножество ext4.

# df /
Файловая система Тип   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/root btrfs   1,4T         1,2T  146G           90% /

# mkdir /test; cd /test
mkdir: создан каталог '/test'

# yes "" | parallel -j32 -n0 --progress --halt soon,fail=1 'dd if=/dev/urandom of=file_{#} bs=1M count=1 status=none'
local:5/148697/100%/0.0s
Computers / CPU cores / Max jobs to run
1:local / 32 / 32

Computer:jobs running/jobs completed/%of started jobs/Average seconds to complete
local:32/148697/100%/0.0s /usr/bin/dd: ошибка записи 'file_148699': На устройстве не осталось свободного места
parallel: This job failed:
dd if=/dev/urandom of=file_148699 bs=1M count=1 status=none
parallel: Starting no more jobs. Waiting for 31 jobs to finish.
<...>

# df /
Файловая система Тип   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/root btrfs   1,4T         1,4T  648K          100% /

# time rm -rf /test; echo $?
rm -rf /test  0,04s user 6,80s system 97% cpu 6,993 total
0

УМВР, ЧЯДНТ? У меня какая-то волшебная btrfs?

Срочно выпустили Debian 12.4, с исправленным ядром 6.1.66. Можно обновляться.

Ээээ… што? Причём тут POSIX вообще?

Это принцип дробления проектов для лучшей отладки и сопровождения. В одеяле они должны писать новый драйвер, копируя туда основу. Если онт пихали всё в старый драйвер, то это тупо.

Напоминаю, что btrfs тем временем как скала.

В смысле объем хранимой инфы как у наскальных рисунков?

У фейсбука то?

И что? Множественное резервирование != надежность fs

Современный ssd убить записью за разумный срок нереально, если специально не захотеть.

Ещё как реально.

Современный ssd убить записью за разумный срок нереально, если специально не захотеть.

Sudo man «энергосберегающие лампочи - вечны»... Теоретик буев.

Sudo man «энергосберегающие лампочи - вечны»... Теоретик буев.

Много чая! Летят только в путь.

Чё ман? Маня, ты сейчас реально примером лампочек пытаешься что-то аргументировать в вопросе ресурса ssd? Мне сложно представить как до такого можно было додуматься. Технологии совершенно разные.

Да, от «стабильного» дистрибутива ожидается в том числе отсутствие багов

Такого в дебиане никогда не было. «Стабильный» - не значит ни «безопасный», ни «без багов»

Чё ман? Маня, ты сейчас реально примером лампочек пытаешься что-то аргументировать в вопросе ресурса ssd? Мне сложно представить как до такого можно было додуматься. Технологии совершенно разные.

Если повезёт то да. А если нет, то инет почитай: слёт прошивки самый распространённый брак. Начали производить в космических маштабах после широкомаштабной рекламы вечности ссд и прошивки пишут на калькуляторе, а чипы га коленке. Друзьям помогает восстановить скорость низкоуровневоетформатирование. Если не помогает, а 1 год уже прошёл то капец. Себе буду брать только intel, даже га samsung evolution ругаются, что некотоые серии бракованные, людит теряют данные. Ты их рекламщик или везучий фанатик? Мне не веришь - инеьу поверь и не позорься своими знаниями.

Да, от «стабильного» дистрибутива ожидается в том числе отсутствие багов.

Ожидание отсутствия багов в линуксах - это такой же вечный и перманентный процесс, как и ожидание Мошиаха иудеями

Ты буквально воспроизводишь мифы про ssd из начала 2010 годов. Разве что забыл про перенос кэша браузера в tmpfs для экономии ресурса. Это всё давно протухло.

после широкомаштабной рекламы вечности ссд

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

Современный ssd убить записью за разумный срок нереально, если специально не захотеть.

Лично я всегда воспринимал ssd как быстрый накопитель, а не долговечный. Ни разу не видел рекламы долговечности.

/0

так это почти любой дистр, особенно без обновлений.

Да, но в дебиане ещё и обновления, как правило, неломающие.

/0

Это ты поделился на ноль или зигу кинул? То что я не воспринимаю ssd как более долговечный накопитель, чем hdd, не делает его менее долговечным. Видите ли долговечность зависит от технологии, а не от мыслей покупателей.

Я ssd, а именно nvme, покупаю ради скорости. То что он при этом ещё и неубиваемый при домашнем использовании это приятный бонус.

Слёт прошивки можно увидеть глазами кода название ssd превратилось из sspc solid state drive, в sata ssd, так слеьаюттпроштвки на phison'е. Это silicon power и dexp.

TheNewDragon в ответ на ваше «Современный ssd убить записью за разумный срок нереально, если специально не захотеть.» имхо вполне нормальную аналогию вам привел.

Если не помогает, а 1 год уже прошёл то капец.

Кое-кто из продованов уже до 10-ти месяцев сократил. При этом более другой все теже 3 года дает.

Ты буквально воспроизводишь мифы про ssd из начала 2010 годов.

Думаю, что при желании можно найти какой-нибудь убогий хлам на 200 гб и ушатать его за несколько лет.

Тоже была такая фигня в сборках ядра xanmod. Обновился до последней

Напоминаю, что btrfs тем временем как скала.

Недавно был баг в xfs, теперь вот в свехстабильной ext4… Долго ли набажить в драйвер btrfs, учитывая что она активно развивается?..

Это та ФС, которая гробит SSD

А можно подробнее? О таком я ещё не слышал…

Это та ФС, которая гробит SSD

А можно подробнее? О таком я ещё не слышал…

Ext4 гробит данные (в том числе в Debian Stable) (комментарий)

Там ссылка на PDF.

Ext4 гробит данные (в том числе в Debian Stable) (комментарий)

Там ссылка на PDF.

О, спасибо! Не знал о таком…

Там ссылка на PDF.

Если почитать полную версию, то видно, что в реальной жизни за пределами искусственных тестов всё не так плохо:

Kernel Compilation

Эмм… а это точно реальная жизнь? Учитывая, что при компиляции ядра запись на диск тащемта минимальна.

На самом деле, я бы на их месте сделал с десяток разделов с разными FS, объединил их в зеркало каким-нибудь overlayfs и замерил бы через полгода при среднем использовании.

/0

Это вы описали, что собираетесь совершить? Не надо, поверьте в этой жизни кроме черных полос встречаются и белые.

… что в реальной жизни за пределами искусственных тестов всё не так плохо

Когда речь идет об обычных файлах, то да. Порой CoW и сжатие даже экономят ресурс накопителя. Беда, когда запись идет внутри файлов-образов или какого-нибудь sqlite, ну и для логов CoW с чексуммами на пользу часто не идет.

В полной статье не нашёл «RAM»: сколько они использовали, какое было давление сбрасывать кэш.

Думаю, что при желании можно найти какой-нибудь убогий хлам на 200 гб и ушатать его за несколько лет.

При желании ушатать можно всё что угодно :)

Эмм… а это точно реальная жизнь? Учитывая, что при компиляции ядра запись на диск тащемта минимальна.

Я бы не назвал Write Cost >6 ГБ минимальной записью на диск. Да и где, по-вашему, сохраняются объектные файлы, созданные при компиляции?

Там у btrfs такой сильный мультипликатор, потому что авторы исследования писали по 4 кБ, дополняя каждую запись вызовом fsync(), т.е. принудительно синхронизировали данные и метаданные ФС, которых у btrfs значительно больше. При обычной буферизованной записи такие мелкие операции группируются, и оверхед от обновления метаданных сильно падает.

На самом деле, я бы на их месте сделал с десяток разделов с разными FS, объединил их в зеркало каким-нибудь overlayfs и замерил бы через полгода при среднем использовании.

Если у вас есть подобные тесты, то было бы интересно взглянуть.

по 4 кБ, дополняя каждую запись вызовом fsync()

Надо было бы обновление пакетов на роллинге deb-дистрибутива потестировать.

Кстати, жаль, что они не обновили статью с добавлением zfs.

Учитывая, что при компиляции ядра запись на диск тащемта минимальна.

Посмотрел на одном из своих *.o
480,346,632 байт
9064 файлов
Ну так себе минимальная.

Я вообще стараюсь не допускать уменьшения свободного пространства ниже одного террабайта. Сразу иду за новым диском.

Мажор.

А как узнать, пострадала ли моя fs от дефектного ведра? Успел накатить, потом ребутнулся в предыдущее, как прочёл о проблеме.

Сделать диф с бэкапом.

Я вообще стараюсь не допускать уменьшения свободного пространства ниже одного террабайта. Сразу иду за новым диском.

Мажор.

Он не написал об области применения в которой так поступает.

Учитывая, что при компиляции ядра запись на диск тащемта минимальна.

Посмотрел на одном из своих *.o

480,346,632 байт

9064 файлов

Ну так себе минимальная.

В сравнении с размером исходников, это не то чтобы много.