| 1.1, Аноним (1), 09:51, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает.
| | |
| |
| 2.2, A.Stahl (ok), 09:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +6 +/– |
 >жить не мешает
приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и мешает реализации новой функциональности
| | |
| |
| 3.8, Kilrathi (ok), 10:12, 09/10/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Если б "мешает реализации новой функциональности" было про "мешает внедрению 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 [^] [^^] [^^^] [ответить]
| +4 +/– | |
У диванных анонимов так всегда...
Для них код как шкаф, который стоит в углу и никому не мешает.
Но такое не так часто.
| | |
| |
| 3.34, Аноним (34), 11:30, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
у диванных проггеров так всегда...
Для них код как шкаф, в котором ничего нельзя найти т.к. полки устарели.
Но такое довольно часто.
| | |
|
| 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, подумай об этом. Как говорил Хемингуэй (или кто там), "идеал -- это не когда больше нечего добавить, а когда больше нечего удалить".
Добавлять код легко. Удалять крайне сложно: тут же выскакивают возмущенные пользователи, которые этим не пользовались, но выскочить и возмутиться хочется. За ними следуют разъяренные начальники, которые настроили метрики КПД по кол-ву добавленных строк, но не удаленных. Также обижаются разрабы оригинального кода: "э, слыш, я в одна тысяча девятьсот лохматом году этот код месяц писал. Целый месяц писал! А ты его щас так просто удаляешь? Пойдем выйдем, раз-на-раз побормочем."
Добавлять код -- это бездумно идти за стадом, сохранять статус-кво, моя хата с краю, "я тут фичу сделяль, влейте". Удалять код -- это по-настоящему смелый мужской поступок, на который решится "не только лишь все". Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а нахрен нам эта хрень вообще упала?"
| | |
|
| 1.3, Аноним (3), 09:56, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>по сравнению с режимами "data=ordered" и "data=writeback"
Ну, writeback, вообще, опасная штука. Такое себе решение дропать журналирование... Сами себе палки в колеса. Я хз, какая там доля ext4 на серверах, но теперь вообще будет 0.
| | |
| |
| 2.5, Другой аноним (?), 10:07, 09/10/2026 [^] [^^] [^^^] [ответить]
| –3 +/– |
Если прочитать получше - журналирование никто дропать не собирался. Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает, ни на 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.36, пох.. (?), 11:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
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 прежде чем рапортовать об успешном успехе - журналу тоже откуда-то нужно узнать, *что* именно тут - транзакция. Держать целиком все данные до закрытия файла он не сможет, потому что файл может закрыться и через пару лет.)
| | |
| 5.40, Аноним (40), 11:53, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге (или в той же ФС) нового файла, а далее - атомарной операции rename.
Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой).
Вот удалить его можно, и переименование с удалением тоже возможно.
| | |
|
|
|
|
| 1.7, Аноним (7), 10:12, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
>Кроме того данная опция не сочетается с некоторыми возможностями, такими как отложенное выделение блоков (delalloc) и прямой ввод/вывод
А может лучше оставить пользователю выбор? Или новый функционал, или полная устойчивость системы?
>мешает реализации новой функциональности в Ext4
Зачем нужно менять именно Ext4? Пускай новый функционал реализуют на уровне VFS.
| | |
| |
| 2.32, Скрудж (?), 11:12, 09/10/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Или новый функционал, или полная устойчивость системы?
Ну так не обновляй ядро, и тебе не будет нового функционала и сохранишь полную устойчивость систему
| | |
|
| 1.9, Аноним (9), 10:12, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Подождите... "в журнал записываются не только метаданные, но и сами данные" разве не приведет к дублированию всех данных на диске и занимаемого места?
| | |
| |
| 2.12, Кирилл (??), 10:16, 09/10/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
Может дублироваться, но только до момента подтверждения записи всей транзакции на диск (т.е. данных), после этого блоки журнала переиспользуются
| | |
| |
| 3.15, Аноним (11), 10:21, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ложь. Размер журнала фиксирован, он не увеличивается и не уменьшается. Увеличивается только количество записей на диск.
| | |
|
| 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 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сопровождает. Успешно. Не бесплатно. Крупные корпы сидят на xfs и btrfs (судя по rhel и suse). Ну, возможно, кто-то ещё на zfs.
А ext4 - удел подкроватных сисадминов с mdadm raid, которые даже не в курсе что такое тихие ошибки и data-integrity.
| | |
| |
| 3.41, Аноним (35), 11:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
ext4 замечательно работает поверх железных рейдов. там все нормально и с тихими ошибками, и резервированием, и проверками на фоне и тд. и даже с пропавшим питанием, если вдруг на ибп пожмотились. речь не про интеловские интеграшки разумеется.
| | |
|
|
| 1.27, RM (ok), 10:58, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 читая новость, приходит только одна мысль, про "неосилили".
| | |
| 1.33, Аноним (34), 11:14, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> но усложняет сопровождение кода
Печально что ядродевелоперы даже с помощью ИИ не могут осилить сопровождение собственного кода.
| | |
| |
| 2.39, пох.. (?), 11:47, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
там как надо девелопер, старик а все сам делал.
Ну вот поэтому такие и пироги.
| | |
|
| 1.43, Аноним (-), 11:55, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев, но усложняет сопровождение кода
Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
| | |
|
