| 1.1, Аноним (1), 09:51, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– |
Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает.
| | |
| |
| 2.2, A.Stahl (ok), 09:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +22 +/– |
 >жить не мешает
приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и мешает реализации новой функциональности
| | |
| |
| 3.8, Kilrathi (ok), 10:12, 09/10/2026 [^] [^^] [^^^] [ответить]
| +10 +/– |
 Если б "мешает реализации новой функциональности" было про "мешает внедрению copy-on-write" - это одно, а вырезать у фс единственный отказоустойчивый режим до/без внедрения альтернативы...
| | |
| |
| 4.70, Аноним (70), 14:31, 09/10/2026 [^] [^^] [^^^] [ответить] | –3 +/– |  Бггг Ну вы ж по иному не возжелаете поработать для гугля и эй-би-эм б 821 е 8... большой текст свёрнут, показать | | |
| 4.113, User (??), 19:38, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если в части "отказоустойчивости" вы полагаетесь на ФС - вы уже очень сильно обо...клались, вот
| | |
| |
| 5.132, Аноним (132), 23:35, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Если в части "отказоустойчивости" вы полагаетесь на ФС - вы уже очень
> сильно обо...клались, вот
О том что стратегии можно при наличии головы совмещать и оптимизировать - клиенту Accenture никто разумеется не рассказал. И правильно, не гоже себе и коллегам бизнеса портить, немамонт должен - доиться.
| | |
|
|
| 3.10, Аноним (10), 10:13, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>приводит к значительному снижению производительности
Если она не нужна. Опция она для этого и существует.
>не сочетается с некоторыми возможностями
Вот это уже политическая борьба внутри системы. Потребителя не спрашивают. Либо круг потребителей противоречивый.
>мешает реализации новой функциональности
Ну сейчас модно новое ради нового. План по новому - новое по плану.
| | |
| 3.11, Аноним (11), 10:15, 09/10/2026 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> приводит к значительному снижению производительности... не сочетается с некоторыми возможностями... и
... обеспечивает высокую устойчивость в случае сбоев.
ПС. Сам пользуюсь этой опцией чуть ли не с самого начала. Жаль :(
| | |
| |
| 4.19, Kilrathi (ok), 10:30, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Классика opensource: либо брать на себя поддержку режима, либо переходить на cow в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs
| | |
| |
| 5.97, Аноним (-), 17:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Классика opensource: либо брать на себя поддержку режима, либо переходить на cow
> в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs
Если вас XFS устраивал то EXT4 тоже так то наверное с теми неполными режимами журнала - пойдет?
| | |
| |
| 6.100, Kilrathi (ok), 18:38, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Если вас XFS устраивал то EXT4 тоже так то наверное с теми
> неполными режимами журнала - пойдет?
Если просто в лоб сравнивать ext4 и xfs в режиме "сферического коня в вакууме": для меня, субъективно, xfs "интереснее".
Если же подбирать не в режиме "ок-по-дефолту", а смотреть по платформе и задачам - уже большая вариативность, не ограничивающаяся этими двумя.
На большинстве используемых мною сейчас систем руты на ext4 и ffs, данные на btrfs и zfs.
В частности/конкретных примерах: на домашнем бюджетном бесшумном минипк под микросервисы система на ext4, виртуалки на xfs, а флешка с бакапами на exfat; на основном пк calibre с зеркалом Флибусты в f2fs, а хостинг служебных ro демо-баз, вообще, в tmpfs...
| | |
| |
| 7.131, Аноним (132), 23:34, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> На большинстве используемых мною сейчас систем руты на ext4 и ffs, данные на btrfs и zfs.
Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов? Necromancy is a forbidden art!
И так то система на btrfs - весьма удобна. Нормальными снапшотами, а заодно и проверкой целостности что в случае глюков хардвара хотя-бы подхайлайтит с фиги ли тут глюкало ором в логи задолго до этого.
| | |
|
|
|
|
| 3.26, Аноним (26), 10:55, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Простое же решение, в данном случае. Нужен максимум производительности - не включай data=journal, нужна повышенная надёжность - включай.
| | |
| 3.122, Кирилл (??), 20:44, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
...решается реорганизацией кода с сохранением отдельной подверсии/подрежима. В котором все конкурирующие опции отключены. Очевидно режим максимальной надёжности это не про ускорение с отложенными операциями.
| | |
| 3.126, Аноним (126), 21:24, 09/10/2026 [^] [^^] [^^^] [ответить] | +1 +/– | Для реализации новой функциональности следует пилить EXT5 или ещё какую-нибудь в... большой текст свёрнут, показать | | |
| |
| 4.147, черпало (?), 01:00, 10/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> EXT4 не выбирают, потому что она более быстрая
Отчего так думаешь? она как раз самая быстрая (настоявшаяся, отполированная), даже если смотреть по количеству инструкций/цпу тайм, я (и не только) замерял и выбирал. Это тебе и простой гуглёж скажет.
| | |
|
| 3.149, Аноним (149), 04:30, 10/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> приводит к значительному снижению производительности...
А оно включено по умолчанию?
| | |
|
| 2.4, iPony128014 (?), 09:57, 09/10/2026 [^] [^^] [^^^] [ответить]
| +7 +/– | |
У диванных анонимов так всегда...
Для них код как шкаф, который стоит в углу и никому не мешает.
Но такое не так часто.
| | |
| |
| 3.34, Аноним (34), 11:30, 09/10/2026 [^] [^^] [^^^] [ответить]
| +10 +/– | |
у диванных проггеров так всегда...
Для них код как шкаф, в котором ничего нельзя найти т.к. полки устарели.
Но такое довольно часто.
| | |
| 3.123, Кирилл (??), 20:47, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Странно, но когда то существовал такой термин как legasy-код, из которого состояло 70++% всего софта и на протяжении примерно 30 лет разработчики каким то образом умели с этим работать, получалось быстро, надёжно, дёшево и функционально. Потом ещё научились делать это безопастно.
Ну а потом пришли новые "разработчики" и решили исправить "быстро, дёшнво, надёжно" да и собственно "работать".
| | |
|
| 2.20, опеншлёпивпродакшн (?), 10:33, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если противников наберётся достаточно - форкнут ext4 и будут сами поддерживать. А если не наберётся, то это ты один такой особенный.
| | |
| |
| 3.42, Аноним (42), 11:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Поддержку данной опции монтирования намерены прекратить в 2028
Люди и дистры просто будут массово сидеть на LTS вышедшем перед проблемной сборкой 2028, пока окончательно не прижмёт. Т.е. аж до самого 19 января 2038, а то и дольше
| | |
| |
| 4.106, _ (??), 19:17, 09/10/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
Нет не будут!
Они и не такое-на-лопате жрали, жрут и будут жрать. К чему иллюзии то?
| | |
|
|
| 2.31, q (ok), 11:09, 09/10/2026 [^] [^^] [^^^] [ответить] | +5 +/– |  Если код только добавлять, но никогда не удалять, то любой проект становится unm... большой текст свёрнут, показать | | |
| |
| 3.61, пох.. (?), 13:27, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а
> нахрен нам эта хрень вообще упала?"
главное задавать его с безопасной дистанции - чтоб тебе при этом не задали встречный - а нахер ТЫ нам, отважный удаляльщик, упал?!
И да, в эпоху ыы безопасной дистанции "вообще в другом городе" может неожиданно перестать хватать.
| | |
| |
| 4.95, Аноним (95), 17:24, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> главное задавать его с безопасной дистанции
Зачем? Потому что т#пого б@дла аргументов нет и в ход пойдут кулаки?
Ну так да, лучше с такими говорить с безопасной дистанции.
| | |
| |
| 5.98, Аноним (11), 17:52, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> лучше с такими говорить с безопасной дистанции.
Зачем вы вообще хотите с такими говорить? Чтоб продемонстрировать им, что они такие а вы не такой?
| | |
| 5.103, Аноним (103), 19:00, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Пишите ваш код так, словно его будет сопровождать после вас маньяк знающий где вы живете (с) дейкстра.
Дебилов-удаляльщиков "я не пользуюсь - значит никто не пользуется" только так и можно учить не лезть своими ручонками туда, куда не просят.
| | |
|
|
| 3.150, Аноним (149), 04:36, 10/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тонна бесполезной словесной софистики.
Удалять нужно не рабочее, сломанное, а не то что работает и даже полезно но ты в это не можешь поэтому это тебе не нужно, а так как ты это подавляющее меньшинство то ты решаешь за всех и делаешь.
Остановите этот мир на минуту, я сойду.
| | |
|
|
| 1.3, Аноним (3), 09:56, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>по сравнению с режимами "data=ordered" и "data=writeback"
Ну, writeback, вообще, опасная штука. Такое себе решение дропать журналирование... Сами себе палки в колеса. Я хз, какая там доля ext4 на серверах, но теперь вообще будет 0.
| | |
| |
| 2.5, Другой аноним (?), 10:07, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если прочитать получше - журналирование никто дропать не собирался. Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает, ни на NTFS, ни на ext4.
| | |
| |
| 3.6, Аноним (3), 10:10, 09/10/2026 [^] [^^] [^^^] [ответить]
| –4 +/– | |
Да, не подумал, что дети на тех.форуме под новостью о полном журналировании в коменте смогут увидеть что-то другое кроме полного журналирования. Именно это и имелось в виду: полное журналирование. Внезапно. Прости, что дропнул это слово. Ведь речь именно об этом в новости. Рукалицо бл.
У меня в проде это критично ибо есть некоторые технические нюансы и требования.
| | |
| |
| 4.23, Другой аноним (?), 10:43, 09/10/2026 [^] [^^] [^^^] [ответить]
| –2 +/– |
Не нравится - используй btrfs, которая для этого и создавалась, полная транзакционность за счёт copy-on-write. Данные гарантированно или записаны целиком, или не записаны совсем.
| | |
| |
| 5.30, Аноним (3), 11:09, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>btrfs
На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру. Да и не имеешь привелегий принимать подобные решения, к сожалению.
| | |
| |
| 6.133, Аноним (132), 23:39, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь
> бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру.
> Да и не имеешь привелегий принимать подобные решения, к сожалению.
А если б даже и имел - случаи бывают разные. Скажем нагруженный БД на cow класть ну такое себе. Можно nocow на ее файлах врубить но тогда большая часть фишек отвалится. И если это был основной сценарий появится вопрос - а за что мы собссно боролись? Перфоманс - просадили, ибо оверхеда все же больше. А взамен с nocow в комплекте ... что?
В общем серебряных пуль все же не бывает. Если кто утверждает обратное, обойдите его стороной - пули у него из другого материала.
| | |
|
|
| 4.35, Аноним (35), 11:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
И как часто в ваш прод попадает свежайшее ядро я кернел орг? Не знаю такого дистра для прода в котором будет 7.3 и выше раньше чем через 2-3 года.
| | |
| 4.49, похнапоха (?), 12:27, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
В продакшене для отказоустойчивости используют надежные СХД с поддержкой (внезапно?) соответствующих потребностям уровней RAID, а так же в дополнение к этому используют метро-кластеры, если данные действительно важные. ext4 в продакшене с опцией data=journal для хранение данных - это баловство, можешь просто использовать пяти дюймовые дискеты для таких данных.
| | |
| |
| 5.85, пох. (?), 16:24, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> В продакшене для отказоустойчивости используют надежные СХД
лучше - сразу облачка, на которых восседает святой дух!
(внезапно, чтобы твои данные добрались до супернадежной [тоже нет] схд - они проходят даже не через одну, а иногда аж через 3 fs - включая и обычную ext4. И да, на КАЖДОМ из этих этапов неуклюжее обращение с данными может что-то испортить.)
главное ж веровать.
| | |
| |
| 6.93, похнапоха (?), 17:03, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Кроме вафли на ONTAP, чего они не скрывают и о чем гордятся, в остальных случаях корпоративные СХД - это простое блочное устройство, с собственной реализацией структур метаданных (конечно ведь снимки как-то должны работать) и тд, но называть это ФС - глупо. А ext4 на СХД - это для iSCSI, что в корпоративном секторе редкость, либо какой-нибудь NAS, что достаточно популярно.
| | |
| 6.118, User (??), 19:51, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ну, внезапно если тебе нужно надёжное хранение данных, то избыточность, ec и вот это всё ты закладываешь вот - на уровне данных, нет?
| | |
| |
| 7.134, пох. (?), 23:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
нет, потому что тогда тебе придется эти данные писать на raw носитель. И то - исключительно в надежде что ну хоть вот фирмварь для самого ссд все же написана нормально.
А то ты избыточность, ec, вот ето все - а там подтверждение записи до самой записи.
И твои избыточные данные - прикрытая несходящимся ec тыковка.
В схд замногоденях тоже нет никакого прямого канала между памятью твоего докера в докере и носителем. А есть та самая ext4 где-то под слоем оверлейфсов, возможно поверх виртуального диска какой-нибудь вмвари, поверх фс уже самой вмвари, которая создана вон там на схд (у которой хотя и не "настоящая" но тоже фс а не прямой доступ к накопителю). Отдельные уровни этой этажерки можно пропускать, но надо хорошо понимать зачем и чем это грозит, а в целом - не рекомендовано.
И _каждый_ из этих уровней должен гарантировать тебе что записанное с fsync - доехало до носителя и будет оттуда прочитано.
(и в идеале бы - что записанное без fsync все равно доедет до носителя хотя бы в большинстве случаев. Потому что fsync стоит дорого. Поэтому вот существуют barriers, тоже по всей этой иерархии.)
| | |
|
|
|
| 4.91, Аноним (91), 16:58, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> У меня в проде это критично ибо есть некоторые технические нюансы и требования.
Ну раз критично аж в проде, то пиши скорее в lkml, предлагай проспонсировать сохранение опции. Это опенсорс, детка, тут никто никому ничего не должен, тут либо сам пишешь что надо, либо ешь что дают.
| | |
|
| |
| 4.36, пох.. (?), 11:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
c silent data corruption works as intended, не забывай уточнять.
потому что журналирование в обход фс и невидимое для нее - всегда вот этим и заканчивается.
| | |
| 4.75, Аноним (74), 14:56, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
В UFS кривейший механизм soft updates, который так и не сделали нормально, а журналирование в geom отдельное от ФС разваливается при первом попадении питания, да так что fsck падает на unexpected soft update inconsistency и файловой системы считай что больше нет.
Но какой идиот будет под FreeBSD использовать не ZFS.
| | |
| |
| 5.94, Kilrathi (ok), 17:11, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> В UFS кривейший механизм soft updates, который так и не сделали нормально,
Вроде как проблемы были в ранних версиях su, а позже поправили (но сам еще со времен 4ки привык ufs без su, а в десятках уже перешел на zfs, так что спорить не буду - ufs + su в проде не гонял)
> журналирование в geom отдельное от ФС разваливается при первом попадении
> питания, да так что fsck падает на unexpected soft update inconsistency
> и файловой системы считай что больше нет.
А это наглядный пример поговорки "если не RTFM, то ССЗБ" - использование одновременно SU и gjournal ;)
Это все равно что под данные прода брать ssd без plp.
Либо мета+данные чисто на журналировании geom без SU, либо SU+J только метаданных средствами фс без geom.
Перепроверился по букварю: https://docs.freebsd.org/en/articles/gjournal-desktop/
Key characteristics of GEOM journaling:
...
Disables Soft Updates
...
Технически они могут работать одновременно, но...
> Но какой идиот будет под FreeBSD использовать не ZFS.
Ответ был на "Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает"
Не смотря на то, что еще 5+ релизов назад gjournal назвали устаревшей после полноценного внедрения zfs, ufs geom все до сих пор в актуальном generic-релизе.
Плюс не стоит забывать про зависимость от производительности: для какой-нибудь домашней файлопомойки на бюджетном одноплатнике с попыткой использовать кучу сервисов/функций в режиме "640кб ОЗУ хватит всем": ufs с geom-журналированием для защиты мета+данные может оказаться более интересной, чем zfs cow.
| | |
| |
| 6.101, Аноним (70), 18:52, 09/10/2026 [^] [^^] [^^^] [ответить] | +/– | Я другой аноним, но у меня кривейший SU ассоциируется лишь c режимом SU J Т... большой текст свёрнут, показать | | |
|
|
| 4.135, Аноним (132), 23:41, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще-то полное журналирование есть в ufs через geom под "фрёй"
Вот только кому весь этот адский кластерфак сдастся и зачем?...
| | |
|
| 3.18, sabitov (ok), 10:29, 09/10/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
 А Вам не доводилось сталкиваться с потерей данных на ФС из-за падения питания? А у меня такое былО, когда в либцэшных .so файлах оказался мусор, а система не бутилась. Я с тех пор XFS не использую :) ХЗ, что там за прошедшие 25 лет поменялось :) И мне пофиг, будет у меня сервер писать 300Мб/с или 250, главное, чтобы при любых раскладах данные не корёжились
| | |
| |
| 4.28, Аноним (3), 11:05, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>сталкиваться с потерей данных
Я думаю, все с этим сталкивались, кто более-менее с компами работает и имеет опыт.
| | |
| 4.29, Другой аноним (?), 11:07, 09/10/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> либцэшных .so файлах оказался мусор
Больше похоже на коррапшен данных по вине диска, не запарковавшего голову, чем на последствие (не)журналирования. Если, конечно, падение питания не произошло в аккурат во время обновления пакета libc, но тут даже журналирование не даст никаких гарантий, потому что если файл наполовину записался - то журнал откатит только половину блоков и получится всё равно битый файл.
В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как именно работает механизм журналирования ФС.
| | |
| |
| 5.38, пох.. (?), 11:46, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
> В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как
> именно работает механизм журналирования ФС.
ты вот, к примеру - кажется, не совсем понимаешь. Что на то и журнал что половина блоков не может записаться. Транзакция либо закрыта, либо нет (и будут заново записаны и те блоки что уже один раз записались и все остальные, либо ничего).
(Ну, в предположении что автор писалки тоже не совсем дол... и дергает 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 [^] [^^] [^^^] [ответить]
| –1 +/– |
По хорошему - да, через rename. И поэтому ситуация, как у автора вызывает больше вопросов, чем ответов. rename - это операция с метой, которая идёт через журнал, даже если data=journal нет. При этом оно /должно/ было случиться уже когда данные в новый .so уже записаны. И уж точно, даже без журнала на ext4 не мог побиться файл, в который не писали. Поэтому либо автор рукоспинствовал, и сделал rename перед записью, после чего писал .so в чистый файл, либо (намного вероятнее) это data corrupt на уровне диска, от которого всё равно никакой журнал не спасёт.
| | |
| 6.53, пох.. (?), 12:57, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге
хачю - делаю, не хачю - не делаю! И чо ты мне сделаешь, я вообще в другом городе!
Вот за такими нехачухами тут надысь километр кода пришлось перебирать, потому что система которая должна была гарантировать надежность данных - внезапно, как оказалось, вообще ничего не гарантирует да еще и в упор не видит потери. Вот то самое хрестоматийное - "а зачем нам коды возврата printf?" вишенкой на тортике.
(хенд мейт между прочим, трю органик, не нейрослоп какой! Вполне вероятно у кого-то до сих пор в проде.)
| | |
| |
| 7.102, Аноним (91), 19:00, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> за такими нехачухами тут надысь километр кода пришлось перебирать
Ну не тебе ж пришлось, а агенту. А ему вообще без разницы, он железный. Ты там небось сидел и лениво пальчиком тыкал в ответы: это хочу, это не хочу, и вообще работай на другом хосте, не шуми мне тут вентилляторами.
> "а зачем нам коды возврата printf?" вишенкой на тортике.
Всегда ли должна функция что-то возвращать, и всегда ли нужно это проверять -- классика, академики ещё в 70х не одну пивную кружку об голову собеседника расхерачили в пылу спора на эти темы. И только потом переключились на algol или lisp, emacs или vim, unix или cp/m.
| | |
| |
| 8.107, пох.. (?), 19:21, 09/10/2026 [^] [^^] [^^^] [ответить] | –1 +/– | да он, сссскотина, вопросы какие-то задает а я ж не настоящий сварщик, я б во... текст свёрнут, показать | | |
|
|
| 6.128, maximnik0 (?), 22:22, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой).
Эта возможность опция, можно блокировку отключить.А юзер файлы записать без блокировки - вообще штатная возможность (root превелегии) .Да и samba тоже может писать без losk файла если это нужно.Механизм простой : записываться новый файл - старый файл помечается как удаленный- но пока дескрипторы заняты, не удаляется.Поэтому через отладку возможно файл восстановить - где то даже howto было на примере видиофайла который проигрывает mplayer ,а каталог удалили.
| | |
|
| 5.44, Аноним (35), 11:58, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
xfs действительно страдал всяческими пропажами при упавшем питании (ядра тогда крэшились тоже частенько, но не про это речь). в нулевых xfs можно было использовать только строго с ибп, это было само собой разумеющимся.
| | |
| 5.71, Аноним (71), 14:32, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
У меня была такая же проблема на ноуте, только там был NVMe от Samsung, Evo 970 вроде бы. Так же поставил ноут обновляться, всё скачалось, началось распаковываться, но происходило это очень медленно. Никаких ошибок в dmesg не было. После ребута нихрена не запустилось, потому что все файлы, в бут разделе в том числе (FAT32), оказались размером 0. Я грешу на фейл проца либо чего-то на материнке, что создаёт коррапт памяти (такое в ноутах делл было со сломанной клавиатурой, а на моём финке как раз у клавы кнопки коротить начали на мембранке), потому что потом с ноутом были такие же проблемы из разряда "чё этот прид*рок делает" и замена диска и плашек оперативки не помогла.
| | |
|
| 4.46, Аноним (46), 12:10, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Xfs вообще интересная в плане багов, занулять рандомные файлы тоже любит и никак это не исправят до конца. Ext4 может повредить открытый на запись файл при data=writeback, но это надо, чтобы звёзды сошлись. После того, как она сотни внезапных отключений энергии подряд переживала без заметных последствий (худшее кэши браузера повреждаются и пару раз экстеншены браузера пришлось обнулить), у меня нет сомнений в её надёжности. Главное, fast_commit не включать, или придётся ждать часами пока убитый журнал регенерирует.
| | |
| |
| 5.77, Аноним (74), 14:58, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> тоже любит и никак это не исправят до конца
Что значит "исправят"? У них в FAQ написано что это бай дизайн
| | |
| |
| 6.108, пох.. (?), 19:26, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> тоже любит и никак это не исправят до конца
> Что значит "исправят"? У них в FAQ написано что это бай дизайн
да это просто местный гений-самоучка без мотора очередной фуфел нашел и без конца про него вспоминает. Наверное бэкап не делал и ценный ридмитхт потерял.
На ext4 в этом файле просто окажется мусор или не окажется самого файла если до барьера попал. Первое гораздо хуже чем очевидно обнуленный файл.
И лечится это правильным написанием кода - вот с теми самыми fsync ДО делания действий которые этот файл считают достоверным, а не чудесами фс.
| | |
|
|
| 4.119, User (??), 19:56, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ну а беда-то в чём? Ну выпала нода из кластера, и?
Или то ЕДИНСТВЕННЫЙ сервер был, второй под кровать не влез?
| | |
|
| 3.66, Метрика (?), 13:49, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Это называется резервным копированием так то, а журналирование это сохранение всех inode файла, чтобы можно было найти его данные на диске, если их не затерли конечно
| | |
|
| 2.127, Аноним (127), 21:41, 09/10/2026 [^] [^^] [^^^] [ответить] | +/– | Ничего там опасного нет вообще Но только, если в программе правильно расставлен... большой текст свёрнут, показать | | |
|
| 1.7, Аноним (7), 10:12, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Кроме того данная опция не сочетается с некоторыми возможностями, такими как отложенное выделение блоков (delalloc) и прямой ввод/вывод
А может лучше оставить пользователю выбор? Или новый функционал, или полная устойчивость системы?
>мешает реализации новой функциональности в Ext4
Зачем нужно менять именно Ext4? Пускай новый функционал реализуют на уровне VFS.
| | |
| |
| 2.32, Скрудж (?), 11:12, 09/10/2026 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Или новый функционал, или полная устойчивость системы?
Ну так не обновляй ядро, и тебе не будет нового функционала и сохранишь полную устойчивость систему
| | |
|
| 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 накопитель.
| | |
| 2.78, Аноним (74), 14:59, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Записать нужно два раза, да, но копию в журнале после подтверждения записи можно больше не хранить.
| | |
|
| 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 [^] [^^] [^^^] [ответить]
| +2 +/– |
ext4 замечательно работает поверх железных рейдов. там все нормально и с тихими ошибками, и резервированием, и проверками на фоне и тд. и даже с пропавшим питанием, если вдруг на ибп пожмотились. речь не про интеловские интеграшки разумеется.
| | |
|
|
| 1.27, RM (ok), 10:58, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 читая новость, приходит только одна мысль, про "неосилили".
| | |
| |
| 2.110, _ (??), 19:32, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
А у меня почему то про "сахар в бензобак"(С) :(
яЪ - ну чё им бтрфс для опытов не хватало? :(
| | |
|
| 1.33, Аноним (34), 11:14, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> но усложняет сопровождение кода
Печально что ядродевелоперы даже с помощью ИИ не могут осилить сопровождение собственного кода.
| | |
| |
| 2.39, пох.. (?), 11:47, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
там как надо девелопер, старик а все сам делал.
Ну вот поэтому такие и пироги.
| | |
| |
| 3.136, Аноним (132), 23:44, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> там как надо девелопер, старик а все сам делал.
> Ну вот поэтому такие и пироги.
Если это про Теодора - он уже давно всем объяснил что гальванизировать ЭТО - смысла вообще осталось довольно мало. А уж сильно развивать или там EXT5 какое - забудьте про это.
Если кому next gen хочется, это не ext5 а скорее структуры как в bcachefs и проч. И Тсо об этом уже тоже догадывается. Как и разработчики btrfs с своими новыми деревьями и проч.
| | |
|
|
| 1.43, Аноним (-), 11:55, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев, но усложняет сопровождение кода
Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
| | |
| |
| 2.65, Метрика (?), 13:44, 09/10/2026 [^] [^^] [^^^] [ответить]
| –3 +/– |
Есть две работающие ФС это NTFS и ZFS, все остальное это попытка студентов в ФС, не более чем
| | |
| |
| 3.109, пох.. (?), 19:28, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Есть две работающие ФС это NTFS и ZFS, все остальное это попытка
> студентов в ФС, не более чем
одна, к сожалению. ТОЙ zfs уже двадцать лет как тоже нет.
| | |
| |
| |
| 5.115, пох.. (?), 19:43, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
та была образцовым копропродуктом поздних 80х, в ней как раз ничего хорошего и не было, ну может кроме идей чуть лучше чем идей extfs из 70х.
насколько хороша та что есть сейчас, существенно переписанная рабами ibm в 2010-2014м - не уверен, поскольку в уже переписанной видел те же глюки что видел в 2009м.
| | |
| |
| 6.141, Аноним (132), 23:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
А чего такого хорошего в блочнике-переростке с типа-переменными блоками для галочки? Сделанным ТАК по причине "мы так привыкли и этот паттерн нас не подводил"? Перфоманс таких структур и оверхед всего этого на современных SSD с зиллионами iops и gbps вызывает у энтерпрайзников только печальку. И никак это особо не починится уже.
Этот мир просто изменился. Сети и IO приблизились к процам по скорости.
| | |
|
|
|
|
| 2.137, Аноним (132), 23:46, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
Btrfs не делает двойную запись при сохранении семантики примерно равной полному журналу. А вот EXT4 очень даже - поэтому сабжевой фичой мало кто пользуется: больно уж это тормозит.
В случае настоящих CoW фокус в первом приближении в том чтобы журналом сделать всю площадь вообще. Тогда комитить в основную область не придется за ее отсутствием. Такой вот нахальный чит. Даже работает в целом.
| | |
| |
| 3.143, пох.. (?), 00:22, 10/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
>> Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
> Btrfs не делает двойную запись при сохранении семантики примерно равной полному журналу.
У нее нет ничего похожего на полный журнал, и она делает не двойную а примерно 16рную.
> В случае настоящих CoW фокус в первом приближении в том чтобы журналом
> сделать всю площадь вообще. Тогда комитить в основную область не придется
> за ее отсутствием. Такой вот нахальный чит. Даже работает в целом.
нет.
журнал либо есть либо его нет вообще. У btrfs его, можно считать, что нет. Зато есть 32-64x оверхед на запись единичного блока. И конечной точкой являются стопиццот копий суперблока, каждую из которых надо обновить чтобы запись одного байтика можно было считать подтвержденной. У ext4 даже с data=journal оверхед минимум вдвое меньше, потому что данные обновляются в том же месте где были, поэтому не надо корректировать указатели на эти данные и указатели на указатели.
| | |
|
|
| 1.47, Аноним (46), 12:13, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Скорее всего это чатботы шалят опять. Ну конечно, будто в ext4 всё остальное работает. У неё куча ограничений и ограничения data=journal не самые худшие (особенно, если они задокументированы).
| | |
| 1.56, pfg21 (ok), 13:03, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 интересно какой процент возмущающихся и почему использует журналирование содержимого в своей практике ??
| | |
| |
| 2.62, пох.. (?), 13:33, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
ну мы когда-то давно обсуждали перспективу хранилки с быстрым ssd (сейчас бы это был наверное dm mirror поверх nvme) для журнала. Т.е. синхронная запись почти мгновенно приземляется в журнале, и возвращает ок, а переписыванием на медленную основную фс мы занимаемся асинхронно и никому не мешаем, данные уже один раз сохранены.
Но по факту разумеется все выбрали готовые промышленные схд.
А поверх ext4 nojournal.
| | |
| |
| |
| 4.117, пох.. (?), 19:45, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> bcachefs ... но аффтЫрь чего то того ... :(
я показывал ссылку на статью 12го года про bcache без fs. Все плохо.
С этим автором каши не сваришь.
только storage space direct спасет мир. Может быть.
(но говорят что как раз это место в ней лучше обходить горными тропами)
| | |
|
|
| 2.120, User (??), 20:11, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Да вот как будто бы и пофиг уже. Вона, даже в postgresql чексуммы на уровне страниц в 18 версии по дефолту включили.
Во всяких block storage навроде недоброй памяти minio erasure coding И избыточность по дефолту, в кафке crc аж в двух местах (но надо знать нюансы), в nosql consistency level На чтение/запись почитай с самого начала - и примерно пофиг, что там под седалищем лежит - нижний слой по определению не надежен.
| | |
| |
| 3.145, пох.. (?), 00:46, 10/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Да вот как будто бы и пофиг уже. Вона, даже в postgresql
> чексуммы на уровне страниц в 18 версии по дефолту включили.
И что будем делать если чексума не совпала - встанем колом и будем ждать бэкап?
> Во всяких block storage навроде недоброй памяти minio erasure coding И избыточность
тоже не для этого.
это дублирование данных на случай отказа носителя. А не потери управления в момент записи. В этом минио точно так же полагается на xfs.
Попытки все слепить в одного монстра - это недоброй памяти ceph. Вот там все в одном, и база данных на raw части носителя, и block storage прямо в физические блоки диска. И неотвратимый п-ц всему, потому что сделать надежно там даже и не думали, да и было им нечем.
| | |
|
|
| |
| 2.59, Аноним (59), 13:21, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Что-то,. помню, она ломалась при любом нештатном выключении питания, требуя ручного запуска fsck после.
| | |
| 2.82, Аноним (48), 16:10, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ее корпораст пилил, она работает. Только фсчек надо из чрут запускать, а то ридонли станет.
| | |
|
| |
| 2.67, Аноним (46), 13:50, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сколько не замерял, то, что они предлагают только снижает общую производительность раз в 10. Больше слушайте этих домохозяек.
| | |
| 2.73, Аноним (71), 14:40, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Во-первых, "Use the journal to optimize performance" - это следующий пункт, сразу после того на который ты ссылку скинул. Во-вторых прочитай что ты скинул. Там сравнение идёт между "data=journal" и дефолтным "data=ordered".
| | |
|
| |
| 2.138, Аноним (132), 23:47, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Почему не сделаю ext5 если ломают обратную совместимость?! Что за идиотизм..
Теодор Тсо предельно ясно высказался по этому поводу. Если ты святее папы римского - сам и девелопай.
| | |
|
| 1.69, DEF (?), 14:23, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Теодор Тцо, разработчик ext4, рекомендует переходить на Btrfs, как на более продвинутую и современную ФС.
| | |
| |
| 2.72, Аноним (72), 14:36, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Значит теперь будут искусственно кастрировать другие файловые системы.
| | |
| |
| |
| 4.130, yylloc (-), 23:14, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Именно, в этом и смысл
Но где?
APFS не загнулась, NTFS тоже. Хотя, не о тех вспомнил. Начинаем: NILFS, QIC, 9fs, NFS, eroFS, exFAT, F2FS, ZFS. Да даже FAT32. Продолжать можно долго, это ещё BSD не упоминаю. btrfs чем так ужасна?
Насчёт слишком раннего выпиливания - полностью согласен. ext4 должна умереть в январе 2038, как и огромное количества не критической legacy инфраструктуры.
| | |
|
|
| 2.76, Аноним (76), 14:57, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Потом выйдет EvenBetterFS и все дружно на неё переходить будем?
| | |
| |
| 3.86, Аноним (86), 16:26, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Есть же bacachefs. Лучшая ФС. Жаль только выпилили побоявшись конкуренции.
| | |
| 3.96, Аноним (95), 17:30, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Потом выйдет EvenBetterFS и все дружно на неё переходить будем?
А почему бы и нет?
Вам цифорка 4 в Ext4 ни на что не намекает?))
Если будет лучше - то разумеется перейдем.
| | |
|
| 2.84, Аноним (48), 16:13, 09/10/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
На СистемД перевели и тут никуда не денуться. Организация одна и та же.
| | |
| 2.88, Аноним (57), 16:35, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
А на ней система за 2 секунды загружается?
А файлы там сами себя пишут, сами проверяют контрольные суммы, а фс это типа композитор?
| | |
| |
| 3.125, _ (??), 20:54, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Не важно.
Не тебе решать что в линуксе юзать. И не мне. Да и * с ним! (C), ну что ж поделаешь?
| | |
| 3.139, Аноним (132), 23:51, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> А на ней система за 2 секунды загружается?
Две не две а одноплатник с 1ГГЦ 1 ядерным 32 бит процом секунд за 5 подымается. С системдой, ога. При том половину занимает декомпресс ядра и проч.
Если скорость монтирования btrfs важна - его надо делать с block group tree. Можно его потом отрастить, требует ядро 6.1 или новее. Так он маунтится... чуть не быстрее сабжа. А если сабж еще и крешнулся и там fsck... ух... ну запустите это на винче терабайт на 5 забитом, посмотреть как вам идея fsck такой шляпы вообще.
| | |
|
|
| 1.83, Инопланетянин (?), 16:13, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев
Получается журналирования данных не будет или есть какая-то другая опция?
| | |
| |
| 2.92, Аноним (92), 17:02, 09/10/2026 [^] [^^] [^^^] [ответить]
| +/– |
Да, не будет. Чтобы клиенты начали покупать специализированные средства.
| | |
|
| 1.87, Cyber100 (ok), 16:32, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 удалить журналирование, которое каждый по желанию мог отключать сам == это гипер-сильно. и на каких таких скоростных устройствах кто-то там заметил якобы тормоза от создания записей транзакций...
| | |
| |
| 2.99, пох.. (?), 18:28, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
тормоза как раз на медленных устройствах - буквально вот 8x write amplification вместо 4x у обычной ext4.
И решалось это выносом лога на сверхбыстрый носитель. Но, кстати, верю что там тоже код тяпляпаный и скорость nvme используется только на треть.
| | |
|
| 1.124, Аноним (124), 20:48, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Ext4 - журналируемая файловая система. Начиная с ядра 7.3 не журналируемая. Как теперь её описывать - Ext4 - журналируемая файловая система до ядра 7.2 включительно. Полужурналируемая система. Недожурналируемая система. Все кто против - старые пердуны, луддиты ретрограды. Главное первым начать громко и чётко стигматизировать тех кто против. Часто вспоминаю времена, когда перешли на Ext4 после Ext2... эх.
| | |
| |
| 2.140, Аноним (132), 23:52, 09/10/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вообще XFS тоже такой полунедожурналируемый. Как и JFS какой. Полный журнал на классике - пишет данные два раза и это комбо посему тормозит как апокалиптец.
| | |
|
| 1.129, ятупойтролль (ok), 22:40, 09/10/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 а в чем проблема сделать ext5? религия не позволяет? нужно сломать то, что уже работает у миллионов людей?
| | |
|
