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

А «stable» должен быть без багов?

12.3

Он же недавно только вышел а уже 3 версия.

Я даже не начал ещё думать об обновлении.

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

У меня как раз 6.1.63. Повезло

В стабильных дистрибутивах баги стабильные, а не сегодня одни, завтра другие

Забей место на 99% на ней и попробуй удалить половину файлов.

Мда, грустно… сейчас ext4, недавно XFS… теперь мало сидеть на стабильном ядре, нужно на старом LTS.

А «stable» должен быть без багов?

Теперь этот баг должны объявить фичей в Debian.

Позволю себе процитировать т-ща shimon:

Хотя, вообще, у дебианщиков (да и многих других) несколько своеобразное представление о стабильности.

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

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

Ну и что, что в других дистрибутивах грабли собрали комбайном? Что с того, что в других дистрибутивах уборка граблей стала процессом постоянным? Это ни черта не значит, ведь это нарушает стабильность. А тут поле с флажками, такое теплое, такое свое, прям как е#учий ЗиЛ «буханка», прости господи, мать твою через коромысло.

Отсюдова: XScreensaver может быть удалён из Debian (комментарий)

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

Это та ФС, которая гробит SSD и при этом не может показать, сколько же у тебя свободного места на диске?

ты не ответил на вопрос

Ну вот в этом случае Debian не виноват. Ядро он всегда использует LTS версии с kernel.org, а не свое, как Ubuntu.

ты не ответил на вопрос

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

Зачем?

Ты про ext4? В btrfs есть режим ssd. Trim поддерживает. Свободное место показывает, но не стандартными командами. И это хорошо. У меня сжатие включено и было бы странным, если бы показывался сжатый размер, а не оригинальный. Это бы сломало много софта.

Ну ты говоришь, что она как скала. ext4 или XFS это выдерживают абсолютно спокойно. И случай в эксплуатации мягко говоря не редкий.

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

где такая сказка на этой планете? Хочу туда.

В btrfs есть режим ssd. Trim поддерживает.

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

https://www.cs.utexas.edu/~vijay/papers/apsys17-ioamp.pdf

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

Што? Все остальные ФС нормально показывают, в том числе со сжатием и т.д. Как это сломает софт-то? На ZFS ничего почему-то из софта не ломается. Я не понимаю, почему ФС не может ответить на очень простой вопрос: сколько я сейчас данных могу записать на диск.

Ну ты говоришь, что она как скала. ext4 или XFS это выдерживают абсолютно спокойно. И случай в эксплуатации мягко говоря не редкий.

Да любая ФС это выдерживает кроме БТР. Вообще, дикость конечно что для удаления файлов нужно свободное место, и если ФС засралась под 0 случайно, то всё, жопа.

Ещё для NILFS2 это в теории представляет проблему, но её уж очень редко используют.

Случай редкий. Я вообще стараюсь не допускать уменьшения свободного пространства ниже одного террабайта. Сразу иду за новым диском. В btrfs он одной командой добавляется в пул и пространство расширяется. Здесь дидовские ФС вообще ничем ответить не могут, а LVM анскильный обрубок.

О норм прога, установил.

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

Пажжи пажжи… ты stripe делаешь? Серьёзно? АХАХАХАХАХАХАХАХАХАХ ГОСПОДИ! Всё, вопросов больше не имею. Ты абсолютно заслуживаешь всего, что тебя ожидает.

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

Про этот момент я знаю. Для домашнего использования неактуально. Современный ssd убить записью за разумный срок нереально, если специально не захотеть. Я себе ни в чём не отказываю и за два года потратил только 10% ресурса по смарту.

Как это сломает софт-то?

Записываю в файл 1 мегабайт, проверяю размер, получается меньше. И чё делать? Очевидно, что система должна показывать оригинальный размер файла, а не сжатый. Иначе много логики в программах сломается.

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

Опять админы подкроватного локалхоста рассуждают о том, какие решения готовы для взрослого продакшена.

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

В btrfs он одной командой добавляется в пул и пространство расширяется. Здесь дидовские ФС вообще ничем ответить не могут, а LVM анскильный обрубок.

На классической связке mdadm + LVM это займет команд 5 примерно, но тоже вполне на ходу. Зато инструменты проверены временем.

Записываю в файл 1 мегабайт, проверяю размер, получается меньше. И чё делать? Очевидно, что система должна показывать оригинальный размер файла, а не сжатый. Иначе много логики в программах сломается.

Чем проверяешь? stat возвращает оригинальный размер и ничо не ломается.

Но к отдельным файлам это отношения не имеет. Смари, всё просто: ZFS умеет и сжатие, и снапшоты, и хера лысого, и при этом df покажет сколько свободно места. Да, при условии сжатия, у тебя при свободных 100 гигах после записи 100 гигов будет ещё дохрена места свободно, потому что эти данные сжались. Но тем не менее, на df можно ориентироваться как на минимальное количество доступного места.

Почему btrfs так не может-то? Ну кроме того, что её писали криворукие обезьяны и в ядро взяли вообще без ревью.

АХАХАХАХАХАХАХАХАХАХ ГОСПОДИ!

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

Я надеюсь ты не из тех, кто делает клоунское резервирование с помощью дублирование данных в рамках одной машины?

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

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

Тебе совсем не жалко будет потратить много часов на восстановление данных из бекапа после отказа RAID0 из-за сбоя на одном диске?

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

Это так. Но по-хорошему нужно и то, и то.

Дело не в избыточности. Дело в том, что stripe далеко не всегда переживает смерть даже одного диска. У тебя вся ФС может пасть смертью храбрых даже если всего один диск сдохнет. Да, даже btrfs.

То есть stripe – это хуже, чем просто руками раскидать данные по дискам. Его для постоянного хранения вообще не надо использовать.

Как я понял, у него RAID0. Эта конфигурация по определению неустойчива к потере любого из дисков.

Как я понял, у него RAID0. Эта конфигурация по определению неустойчива к потере любого из дисков.

Ну типа, есть шанс, что фс переживёт пропажу части блоков и он тупо данные с мёртвого диска потеряет. Но я бы на это не рассчитывал.

Опять админы подкроватного локалхоста рассуждают о том, какие решения готовы для взрослого продакшена.

Ты с кем разговариваешь? У меня нет ни одного сервера, ни подкроватного ни какого. Админство это для людей в чёрном теле.

На классической связке mdadm + LVM это займет команд 5

На этой связке невозможно. У меня несколько разделов используют общее свободное пространство. LVM так умеет только в режиме thin pool, но он кривой и может убить ФС при переполнении. Дидовские технологии здесь бессильны.

Так и в btrfs df даст оценку свободного места, а stat точный размер файла. И чем твой кривой zfs тут лучше?

У меня нет ни одного сервера, ни подкроватного ни какого.

Тогда может перестанешь рассуждать о готовности технологий в основной сфере использования Linux, раз у тебя нет в ней опыта?

У меня несколько разделов используют общее свободное пространство. LVM так умеет только в режиме thin pool, но он кривой и может убить ФС при переполнении.

Да, это классические технологии не умеют. Но, справедливости ради, это нужно не столь уж часто.

Так и в btrfs df даст оценку свободного места

Не, не даст. Он там часто полную херь показывает.

Мне нравится вот эта тема:

With BTRFS, it is possible to run out of space when writing an amount of data that is much less than the reported free space.

This is because BTRFS starts every write in a freshly allocated chunk. But as the chunksize is static, and files come in all sizes, much of the time a chunk is incompletely filled. That creates “allocated but not used” space that is the problem.

https://superuser.com/a/1582976

И чем твой кривой zfs тут лучше?

Даже не знаю. Тем, что переживает переполнение диска любым сраным баш скриптом? Я понимаю, фишка редкая среди ФС, не всем нужно.

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

У меня не датацентр, чтобы на экономии времени можно было бы выиграть.

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

в основной сфере использования Linux, раз у тебя нет в ней опыта?

Встраиваемые устройства и мобильные телефоны? Это наше обсуждение как раз и не затрагивает основную сферу использования линукса.

Окей, но вторая по значимости — сервера, а не десктопы.

Не, не даст.

Лично я не сталкивался с описанной проблемой. Доводил диск до 90% занятого пространства по df. Никаких внезапных исчерпаний места не проищошло. Процитированный анон возможно поймал проблему в лохматые годы, но продолжает проецировать на нынешнее состояние дел.

Тем, что переживает переполнение диска любым сраным баш скриптом?

Не представляю как убить btrfs баш скриптом. Это какие-то фантазии.

Не, не даст.

Лично я не сталкивался с описанной проблемой. Доводил диск до 90% занятого пространства по df. Никаких внезапных исчерпаний места не проищошло. Процитированный анон возможно поймал проблему в лохматые годы, но продолжает проецировать на нынешнее состояние дел.

Там 2021 год. Проблема в самом формате данных, так что ничо не изменилось.

Тем, что переживает переполнение диска любым сраным баш скриптом?

Не представляю как убить btrfs баш скриптом. Это какие-то фантазии.

while : ; do
  dd if=/dev/urandom of="~/file-$RANDOM" bs=1M count=1
done

Попробуй. Тебе понравится!

Ну ты зверь. Хотя я попробую — на виртуалке, конечно.

Ну ты зверь. Хотя я попробую — на виртуалке, конечно.

Нафига? Просто создай ФС в файле, примонтируй и развлекайся.

Завтра точнее уже сегодня проверю скрипт.

Главное не на основном хранилище.

Конечно нет. У меня там 4 ТБ.

Вместо $RANDOM лучше $(uuid) использовать. Так нет шансов, что закончятся варианты.

Или банальные номера со счетчиком.

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

2 месяца без обновлений, и, вдруг, именно с критическим багом:

linux-signed-amd64 (6.1.64+1) bookworm; urgency=medium
 ...
 -- ... Thu, 30 Nov 2023 16:41:14 +0100

linux (6.1.55-1) bookworm; urgency=medium
 ...
 -- ... Fri, 29 Sep 2023 06:15:31 +0200

Подозрительно это…

#!/bin/bash
a=0
while true
do
dd if=/dev/urandom of=$a bs=1M count=1 >/dev/null 2>&1
a=$(( $a + 1 ))
done

Запускать в той директории, что хочешь засрать.

Проверил только что на openSUSE Leap 15.5 Server в VirtualBox — эту директорию потом я успешно удалил после 100% заполнения /, да ещё и записал новые данные на диск после удаления. Так что btrfs видимо не столь плоха, как я думал.

Fedora Workstation 39 тоже выдержала.