| 1.1, Аноним (1), 09:51, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает.
| | |
| |
| 2.2, A.Stahl (ok), 09:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +9 +/– |
 >жить не мешает
приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и мешает реализации новой функциональности
| | |
| |
| 3.8, Kilrathi (ok), 10:12, 09/10/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Если б "мешает реализации новой функциональности" было про "мешает внедрению copy-on-write" - это одно, а вырезать у фс единственный отказоустойчивый режим до/без внедрения альтернативы...
| | |
| 3.10, Аноним (10), 10:13, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>приводит к значительному снижению производительности
Если она не нужна. Опция она для этого и существует.
>не сочетается с некоторыми возможностями
Вот это уже политическая борьба внутри системы. Потребителя не спрашивают. Либо круг потребителей противоречивый.
>мешает реализации новой функциональности
Ну сейчас модно новое ради нового. План по новому - новое по плану.
| | |
| 3.11, Аноним (11), 10:15, 09/10/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> приводит к значительному снижению производительности... не сочетается с некоторыми возможностями... и
... обеспечивает высокую устойчивость в случае сбоев.
ПС. Сам пользуюсь этой опцией чуть ли не с самого начала. Жаль :(
| | |
| |
| 4.19, Kilrathi (ok), 10:30, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Классика opensource: либо брать на себя поддержку режима, либо переходить на cow в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs
| | |
|
| 3.26, Аноним (26), 10:55, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Простое же решение, в данном случае. Нужен максимум производительности - не включай data=journal, нужна повышенная надёжность - включай.
| | |
|
| 2.4, iPony128014 (?), 09:57, 09/10/2026 [^] [^^] [^^^] [ответить]
| +5 +/– | |
У диванных анонимов так всегда...
Для них код как шкаф, который стоит в углу и никому не мешает.
Но такое не так часто.
| | |
| |
| 3.34, Аноним (34), 11:30, 09/10/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
у диванных проггеров так всегда...
Для них код как шкаф, в котором ничего нельзя найти т.к. полки устарели.
Но такое довольно часто.
| | |
|
| 2.20, опеншлёпивпродакшн (?), 10:33, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если противников наберётся достаточно - форкнут ext4 и будут сами поддерживать. А если не наберётся, то это ты один такой особенный.
| | |
| |
| 3.42, Аноним (42), 11:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Поддержку данной опции монтирования намерены прекратить в 2028
Люди и дистры просто будут массово сидеть на LTS вышедшем перед проблемной сборкой 2028, пока окончательно не прижмёт. Т.е. аж до самого 19 января 2038, а то и дольше
| | |
|
| 2.31, q (ok), 11:09, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > дай да выпилить что-нибудь что не сломано и жить не мешает
Если код только добавлять, но никогда не удалять, то любой проект становится unmaintainable, подумай об этом. Как говорил Хемингуэй (или кто там), "идеал -- это не когда больше нечего добавить, а когда больше нечего удалить".
Добавлять код легко. Удалять крайне сложно: тут же выскакивают возмущенные пользователи, которые этим не пользовались, но выскочить и возмутиться хочется. За ними следуют разъяренные начальники, которые настроили метрики КПД по кол-ву добавленных строк, но не удаленных. Также обижаются разрабы оригинального кода: "э, слыш, я в одна тысяча девятьсот лохматом году этот код месяц писал. Целый месяц писал! А ты его щас так просто удаляешь? Пойдем выйдем, раз-на-раз побормочем."
Добавлять код -- это бездумно идти за стадом, сохранять статус-кво, моя хата с краю, "я тут фичу сделяль, влейте". Удалять код -- это по-настоящему смелый мужской поступок, на который решится "не только лишь все". Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а нахрен нам эта хрень вообще упала?"
| | |
| |
| 3.61, пох.. (?), 13:27, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а
> нахрен нам эта хрень вообще упала?"
главное задавать его с безопасной дистанции - чтоб тебе при этом не задали встречный - а нахер ТЫ нам, отважный удаляльщик, упал?!
И да, в эпоху ыы безопасной дистанции "вообще в другом городе" может неожиданно перестать хватать.
| | |
|
|
| 1.3, Аноним (3), 09:56, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>по сравнению с режимами "data=ordered" и "data=writeback"
Ну, writeback, вообще, опасная штука. Такое себе решение дропать журналирование... Сами себе палки в колеса. Я хз, какая там доля ext4 на серверах, но теперь вообще будет 0.
| | |
| |
| 2.5, Другой аноним (?), 10:07, 09/10/2026 [^] [^^] [^^^] [ответить]
| –4 +/– |
Если прочитать получше - журналирование никто дропать не собирался. Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает, ни на NTFS, ни на ext4.
| | |
| |
| 3.6, Аноним (3), 10:10, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Да, не подумал, что дети на тех.форуме под новостью о полном журналировании в коменте смогут увидеть что-то другое кроме полного журналирования. Именно это и имелось в виду: полное журналирование. Внезапно. Прости, что дропнул это слово. Ведь речь именно об этом в новости. Рукалицо бл.
У меня в проде это критично ибо есть некоторые технические нюансы и требования.
| | |
| |
| 4.23, Другой аноним (?), 10:43, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Не нравится - используй btrfs, которая для этого и создавалась, полная транзакционность за счёт copy-on-write. Данные гарантированно или записаны целиком, или не записаны совсем.
| | |
| |
| 5.30, Аноним (3), 11:09, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>btrfs
На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру. Да и не имеешь привелегий принимать подобные решения, к сожалению.
| | |
|
| 4.35, Аноним (35), 11:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
И как часто в ваш прод попадает свежайшее ядро я кернел орг? Не знаю такого дистра для прода в котором будет 7.3 и выше раньше чем через 2-3 года.
| | |
| 4.49, похнапоха (?), 12:27, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
В продакшене для отказоустойчивости используют надежные СХД с поддержкой (внезапно?) соответствующих потребностям уровней RAID, а так же в дополнение к этому используют метро-кластеры, если данные действительно важные. ext4 в продакшене с опцией data=journal для хранение данных - это баловство, можешь просто использовать пяти дюймовые дискеты для таких данных.
| | |
|
| |
| 4.36, пох.. (?), 11:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
c silent data corruption works as intended, не забывай уточнять.
потому что журналирование в обход фс и невидимое для нее - всегда вот этим и заканчивается.
| | |
|
| 3.18, sabitov (ok), 10:29, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
 А Вам не доводилось сталкиваться с потерей данных на ФС из-за падения питания? А у меня такое былО, когда в либцэшных .so файлах оказался мусор, а система не бутилась. Я с тех пор XFS не использую :) ХЗ, что там за прошедшие 25 лет поменялось :) И мне пофиг, будет у меня сервер писать 300Мб/с или 250, главное, чтобы при любых раскладах данные не корёжились
| | |
| |
| 4.28, Аноним (3), 11:05, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>сталкиваться с потерей данных
Я думаю, все с этим сталкивались, кто более-менее с компами работает и имеет опыт.
| | |
| 4.29, Другой аноним (?), 11:07, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> либцэшных .so файлах оказался мусор
Больше похоже на коррапшен данных по вине диска, не запарковавшего голову, чем на последствие (не)журналирования. Если, конечно, падение питания не произошло в аккурат во время обновления пакета libc, но тут даже журналирование не даст никаких гарантий, потому что если файл наполовину записался - то журнал откатит только половину блоков и получится всё равно битый файл.
В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как именно работает механизм журналирования ФС.
| | |
| |
| 5.38, пох.. (?), 11:46, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как
> именно работает механизм журналирования ФС.
ты вот, к примеру - кажется, не совсем понимаешь. Что на то и журнал что половина блоков не может записаться. Транзакция либо закрыта, либо нет (и будут заново записаны и те блоки что уже один раз записались и все остальные, либо ничего).
(Ну, в предположении что автор писалки тоже не совсем дол... и дергает fsync/dsync прежде чем рапортовать об успешном успехе - журналу тоже откуда-то нужно узнать, *что* именно тут - транзакция. Держать целиком все данные до закрытия файла он не сможет, потому что файл может закрыться и через пару лет.)
| | |
| |
| 6.51, Другой аноним (?), 12:43, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ситуация, описываемая автором настолько странная, что там либо кривая писалка была, которая после каждого блока fsync'ала, либо (что вероятнее) это было повреждение данных на уровне HDD, от которого журнал никак бы не спас, ибо оно не для этого.
| | |
| |
| 7.52, пох.. (?), 12:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
не, ну можно ж вообще не фсинкать? а я хрен знает как всякие dpkg принято было писать в том самом ламповом 93м.
Файл открываем сразу тот который обновляем, никаких этих вам mkstemp/rename, читаем откуда-то пишем куда-то вперемешку, чтоб шибкоумная фс не могла предугадать наших действий, надо быть непредсказуемым для противника, где-нибудь по дороге еще тупим (например потому что чтение подзависло на фоне записи), прилетает внезапное отключение электричества - проооофит!
с повреждениями на hdd у нас все плохо с тех пор как секторные метки начали записывать вместе с данными - будет сбойный сектор, а это слишком заметно.
| | |
|
|
| 5.40, Аноним (40), 11:53, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге (или в той же ФС) нового файла, а далее - атомарной операции rename.
Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой).
Вот удалить его можно, и переименование с удалением тоже возможно.
| | |
| |
| 6.50, Другой аноним (?), 12:38, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
По хорошему - да, через rename. И поэтому ситуация, как у автора вызывает больше вопросов, чем ответов. rename - это операция с метой, которая идёт через журнал, даже если data=journal нет. При этом оно /должно/ было случиться уже когда данные в новый .so уже записаны. И уж точно, даже без журнала на ext4 не мог побиться файл, в который не писали. Поэтому либо автор рукоспинствовал, и сделал rename перед записью, после чего писал .so в чистый файл, либо (намного вероятнее) это data corrupt на уровне диска, от которого всё равно никакой журнал не спасёт.
| | |
| 6.53, пох.. (?), 12:57, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге
хачю - делаю, не хачю - не делаю! И чо ты мне сделаешь, я вообще в другом городе!
Вот за такими нехачухами тут надысь километр кода пришлось перебирать, потому что система которая должна была гарантировать надежность данных - внезапно, как оказалось, вообще ничего не гарантирует да еще и в упор не видит потери. Вот то самое хрестоматийное - "а зачем нам коды возврата printf?" вишенкой на тортике.
(хенд мейт между прочим, трю органик, не нейрослоп какой! Вполне вероятно у кого-то до сих пор в проде.)
| | |
|
| 5.44, Аноним (35), 11:58, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
xfs действительно страдал всяческими пропажами при упавшем питании (ядра тогда крэшились тоже частенько, но не про это речь). в нулевых xfs можно было использовать только строго с ибп, это было само собой разумеющимся.
| | |
|
| 4.46, Аноним (46), 12:10, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Xfs вообще интересная в плане багов, занулять рандомные файлы тоже любит и никак это не исправят до конца. Ext4 может повредить открытый на запись файл при data=writeback, но это надо, чтобы звёзды сошлись. После того, как она сотни внезапных отключений энергии подряд переживала без заметных последствий (худшее кэши браузера повреждаются и пару раз экстеншены браузера пришлось обнулить), у меня нет сомнений в её надёжности. Главное, fast_commit не включать, или придётся ждать часами пока убитый журнал регенерирует.
| | |
|
|
|
| 1.7, Аноним (7), 10:12, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Кроме того данная опция не сочетается с некоторыми возможностями, такими как отложенное выделение блоков (delalloc) и прямой ввод/вывод
А может лучше оставить пользователю выбор? Или новый функционал, или полная устойчивость системы?
>мешает реализации новой функциональности в Ext4
Зачем нужно менять именно Ext4? Пускай новый функционал реализуют на уровне VFS.
| | |
| |
| 2.32, Скрудж (?), 11:12, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Или новый функционал, или полная устойчивость системы?
Ну так не обновляй ядро, и тебе не будет нового функционала и сохранишь полную устойчивость систему
| | |
|
| 1.9, Аноним (9), 10:12, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Подождите... "в журнал записываются не только метаданные, но и сами данные" разве не приведет к дублированию всех данных на диске и занимаемого места?
| | |
| |
| 2.12, Кирилл (??), 10:16, 09/10/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
Может дублироваться, но только до момента подтверждения записи всей транзакции на диск (т.е. данных), после этого блоки журнала переиспользуются
| | |
| |
| 3.15, Аноним (11), 10:21, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ложь. Размер журнала фиксирован, он не увеличивается и не уменьшается. Увеличивается только количество записей на диск.
| | |
| |
| 4.54, пох.. (?), 12:58, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Ложь. Размер журнала фиксирован
да вроде нет? Ты с journal inode не перепутал?
| | |
|
|
| 2.16, Аноним (16), 10:29, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Приводит. Но обычно для этого используют отдельный SSD накопитель.
| | |
|
| 1.17, Аноним (17), 10:29, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>но усложняет сопровождение кода
Но ведь сейчас ИИ из всех утюгов с историями успеха по сопровождению кода, как это может быть аргументов в 2026 году ?
| | |
| |
| 2.25, Аноним (25), 10:55, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Сопровождает. Успешно. Не бесплатно. Крупные корпы сидят на xfs и btrfs (судя по rhel и suse). Ну, возможно, кто-то ещё на zfs.
А ext4 - удел подкроватных сисадминов с mdadm raid, которые даже не в курсе что такое тихие ошибки и data-integrity.
| | |
| |
| 3.41, Аноним (35), 11:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
ext4 замечательно работает поверх железных рейдов. там все нормально и с тихими ошибками, и резервированием, и проверками на фоне и тд. и даже с пропавшим питанием, если вдруг на ибп пожмотились. речь не про интеловские интеграшки разумеется.
| | |
|
|
| 1.27, RM (ok), 10:58, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 читая новость, приходит только одна мысль, про "неосилили".
| | |
| 1.33, Аноним (34), 11:14, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> но усложняет сопровождение кода
Печально что ядродевелоперы даже с помощью ИИ не могут осилить сопровождение собственного кода.
| | |
| |
| 2.39, пох.. (?), 11:47, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
там как надо девелопер, старик а все сам делал.
Ну вот поэтому такие и пироги.
| | |
|
| 1.43, Аноним (-), 11:55, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев, но усложняет сопровождение кода
Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
| | |
| |
| 2.65, Метрика (?), 13:44, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Есть две работающие ФС это NTFS и ZFS, все остальное это попытка студентов в ФС, не более чем
| | |
|
| 1.47, Аноним (46), 12:13, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Скорее всего это чатботы шалят опять. Ну конечно, будто в ext4 всё остальное работает. У неё куча ограничений и ограничения data=journal не самые худшие (особенно, если они задокументированы).
| | |
| 1.56, pfg21 (ok), 13:03, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 интересно какой процент возмущающихся и почему использует журналирование содержимого в своей практике ??
| | |
| |
| 2.62, пох.. (?), 13:33, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
ну мы когда-то давно обсуждали перспективу хранилки с быстрым ssd (сейчас бы это был наверное dm mirror поверх nvme) для журнала. Т.е. синхронная запись почти мгновенно приземляется в журнале, и возвращает ок, а переписыванием на медленную основную фс мы занимаемся асинхронно и никому не мешаем, данные уже один раз сохранены.
Но по факту разумеется все выбрали готовые промышленные схд.
А поверх ext4 nojournal.
| | |
|
| 1.64, Метрика (?), 13:42, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Уровень ядра леньки поражает, называть журналированием резервное копирование? Зря не слушал он Таненбаума ой зря
| | |
|
