Разработчики из компании SUSE предложили (https://lkml.org/lkml/2015/7/15/438) удалить драйвер ext3 из состава ядра Linux. В качестве мотива удаления отмечается, что драйвер является лишним и дублирует уже имеющуюся в другом драйвере функциональность. В частности, функции работы с разделами ext3 имеются в драйвере ext4, который полностью обратно совместим с прошлым поколением ФС. Theodore Ts'o, создатель и основной разработчики файловой системы Ext* одобрил (https://lkml.org/lkml/2015/7/15/607) данное предложение, но уточнил, что необходимо предусмотреть возможность замены параметра CONFIG_FS_EXT3 на
CONFIG_FS_EXT4 в конфигурациях, в которых была включена только поддержка Ext3.URL: https://lkml.org/lkml/2015/7/15/438
Новость: http://www.opennet.me/opennews/art.shtml?num=42608
Там люди ещё думают, не удалить ли попутно data=journal
прискорбно слышать
что за бред?
> что за бред?прошу прощения, journal=data, конечно же
я не об этом, что за бред убирать нужный работающий механизм который использует куча людей?!!
> что за бред убирать нужный работающий механизм который использует куча людей?!!Разработчики ядра (в лице Эндрю Мортона) не знали, что этим кто-то пользуется. Но один человек там уже написал, что использует, так что пока вопрос снят.
Смущает, скорее, то, что удалить хотят фактически единственную опцию, позволяющую получить достаточно надёжное файловое хранилище без покупки UPS.
mount -o sync ... не ?
> mount -o sync ... не ?тормозит же. как msdos будет.
Давно пора. Можно ещё и JFS с ReiserFS выкинуть, всё равно RIP.
jfs не трожь
Собирал как-то openwrt для роутера с 4мб флеша, чтобы уместить морду, под нож ушли все драйвера фс кроме ext2 и fat32.
fat32 - вот его-то и надо было в первую очередь по нож. А microSDшки для роутера форматировать в Ext2/3.
Оставить ReiserFS. Работает и кушать не просит.
Его жена так не считала.
Но fs хорошая.
> Давно пора.Речь совсем о другом -- есть дублирующиеся драйверы файловых систем ext[234], при этом в ext4.ko продублирована также и функциональность ext2.ko (но её не выкидывают, скорее всего, по причине компактности кода, который может быть полезен на системах, где ext3/ext4 избыточны). При этом, если правильно помню рассказ led@ времён создания CONFIG_EXT4_USE_FOR_EXT23, ext4.ko как замена ext3.ko ещё и оптимальней может быть на той же ФС.
>> Давно пора.
> Речь совсем о другом -- есть дублирующиеся драйверы файловых систем ext[234], при
> этом в ext4.ko продублирована также и функциональность ext2.ko (но её не
> выкидывают, скорее всего, по причине компактности кода, который может быть полезен
> на системах, где ext3/ext4 избыточны). При этом, если правильно помню
> рассказ led@ времён создания CONFIG_EXT4_USE_FOR_EXT23, ext4.ko как замена ext3.ko ещё
> и оптимальней может быть на той же ФС.оптимальней только за счет прозрачного включения фичей от ext4.
в остальном - тоже убожество что и ext4. Сделать hash tree для поиска имени в каталоге, но не доделать и бросить на пол пути, это только в Linux могут.
Последний блок дает up 300-400 строковых сравнений, да .. не миллионы - но тоже не весело.
при удалении файлов - никто не собирается удалять лишние записи в hash tree.
тормоза в каталоге после длительного создания/удаления файлов - это притча на языках, иногда e2fsck -D помогает, иногда нет.лимит файла на 16T и дикое разрастание метаданных на больших дисках - это отдельная грустная песня.
Но есть же вполне нормальная и рабочая ZFS ?
"Нормальная ZFS", лол. Ещё что-нибудь скажи.
ZFS лучшая файловая система, лол.
Да-да, "лол" -))
> Но есть же вполне нормальная и рабочая ZFS ?Ога, без нормальных экстентов, без нормального управления памятью кэша, CoW но без дефрагера, без возможности CoW выборочно отключить там где мешается. Ну и нафига оно такое надо?
Для хранилок надо. Для виртуализаторов тоже неплохо ("бесплатный" /ценой изначальной "тормознутости"/ клон раздела). Где-то вот в эту нишу.
Ну и киллер-фича: репликация раздела путём передачи журнала изменений от момента последнего снапота. Где оно актуально — там zfs без вариантов.
Для "common use" — ну извините, слегка заоверинжинирили.
> Для хранилок надо.Для весьма специфичных хранилок. Ну и в линухе ее имхо вытурит btrfs. А просто потому что он там по дефолту есть. Сразу и без приседаний. А дефолты, как известно, решают.
> Для виртуализаторов тоже неплохо ("бесплатный" /ценой изначальной
> "тормознyтости"/ клон раздела).На btrfs "cp --reflink=always" нынче вполне себе работает. Да, при этом можно сделать клон виртуалки на хренадцать гигз за три секунды.
Но для виртуализаторов плохо много чего еще. CoW клeщится с CoW логикой диска-в-файле у VM. И надо его отключать в одном из двух мест - или у виртуализатора RAW диск и все снапшотные операции только на уровне ФС, или в файлухе запретить CoW и все снапшотные операции только виртуализатором. Иначе будет CoW Cow'а, а это двойная работа и over 9000 фрагментов. Btrfs и тут в плюсе - позволяет nodatacow сказать. Актуально, если хочется рулить снапшотами средствами виртуализатора и его CoW-файлов.
> момента последнего снапота. Где оно актуально — там zfs без вариантов.
Да размечтался, плюшевый: send/receive в btrfs уже давно запилили. Твои знания протухли.
> Для "common use" — ну извините, слегка заоверинжинирили.Ну а у меня btrfs даже на рутфс ноута стоит - нормальненько вполне. Ресурсов оптом не лопает, управление памятью нормальное, все дела. Так на глаз от ext4 и не отличишь особо. А вот отмотать на снпшот при факапе - мысль достаточно интересная, что ни говори. Как и CoW-backed файлы с множественным референсом.
> без возможности CoW выборочно отключить там где мешается.Ты вообще в курсе, какие настраиваемые свойства есть у ZFS?
> Ну и нафига оно такое надо?
///---https://www.linux.org.ru/forum/admin/11776202#comment-11777452
Среди случаев практического использования [фичи внешнего кэширования - L2ARC] могу вспомнить одного чувака с гигабитным интернетом, который хотел раздавать торренты. Так вот, у него скорость была нормальная только на 1-3 раздачах, больше она жостко резалась еще на уровне случайного чтения с пула на hdd, он воткнул ssd под L2ARC, через некоторое время торренты закешировались и он получил гигабит на 30+ одновременных активных раздачах.
---///
> Ты вообще в курсе, какие настраиваемые свойства есть у ZFS?И как же отключить CoW на ZFS?
> И как же отключить CoW на ZFS?zfs set sync=disabled <filesystem>
Нет ZIL == нет CoW.
> Ты вообще в курсе, какие настраиваемые свойства есть у ZFS?Ну так ты как эксперт - даш нам краткий курс как отключить CoW для вон того конкретного файлика? Допустим, виртуалка лежит в /VM/Debian/debian-8-64bit.qcow. Мои действия?
> жостко резалась еще на уровне случайного чтения с пула на hdd,
Это называется "торрент-клиент не умеет в application-specific кэширование". И костыльнуть кэшом общего назначения конечно можно. Но намного лучше когда торрент клиент умеет упреждающее чтение и direct io, т.к. торрент клиент лучше операционки и ФС знает какой кусок файла он будет отгружать дальше и может его заранее подчитать до того как понадобится. И I/O при этом может быть не рандомный а относительно последовательный и крупноблочный (в зависимости от жабы на память под такой кастомный кэш).
Приколись, это один из тех самых случаев когда app-level cache заруливает кэши общего назначения. ФС тут вообще скорее мешается.
> он воткнул ssd под L2ARC, через некоторое время торренты закешировались и
> он получил гигабит на 30+ одновременных активных раздачах.Остается вопрос: через сколько в SSD протрется дырка. Я думаю что довольно быстро, если пиры будут разные раздачи просить. Не говоря о том что пока оно не закешировалось - пиры сталкиваются с пониженной производительностью.
>> Ты вообще в курсе, какие настраиваемые свойства есть у ZFS?
> Ну так ты как эксперт - даш нам краткий курс как отключить
> CoW для вон того конкретного файлика? Допустим, виртуалка лежит в /VM/Debian/debian-8-64bit.qcow.
> Мои действия?Твои действия начинаются с прочтения официальной документации по администрированию ZFS от компании Oracle на русском языке прежде, чем что-то делать. Но пока ты и это не осилил. (Я уж не говорю о том, что у тебя даже нет ZFS пула, чтобы что-то там "настраивать" с моей помощью).
Так ты скажи всё-таки, как отключить CoW на ZFS?
> Твои действия начинаются с прочтения официальной документации по администрированию ZFSТак все-таки, как мне отключить CoW для указанного файла? А в документации там всякий маркетинговый булшит.
> от компании Oracle на русском языке прежде, чем что-то делать.
Я технарь а не домохозяйка. Поэтому и на английском могу прочитать, если надо.
> том, что у тебя даже нет ZFS пула, чтобы что-то там
> "настраивать" с моей помощью).Конечно нет. Зачем он мне, если пулы на btrfs собираются с штатными майнлайновыми ядрами, без левых приключений. И CoW там отключается. Пофайлово. И интеграция с системой нормальная - и всякие там O_TMPFILE работают, и память кэша управляется нормально, и cp --reflink работает.
Но есть же вполне нормальная и рабочая XFS !
Подскажи, как уменьшить её размер.
> Подскажи, как уменьшить её размер.Можно давно отмонтированные разделы уменьшать ,даже в lvm .
Подскажите как прекратить фрагментацию XFS по CronTab ?
> Подскажите как прекратить фрагментацию XFS по CronTab ?man xfs_fsr
man crontab
> Последний блок дает up 300-400 строковых сравнений, да .. не миллионы -
> но тоже не весело.Тем не менее, в среднем по больнице - работает весьма шустро. Ну так, судя по тому как бенчи соотносятся с остальными.
> это отдельная грустная песня.
Только поет ее полтора человека на планету.
>> Последний блок дает up 300-400 строковых сравнений, да .. не миллионы -
>> но тоже не весело.
> Тем не менее, в среднем по больнице - работает весьма шустро. Ну
> так, судя по тому как бенчи соотносятся с остальными.Вы видели хоть одни бенчи для aged system? вот и все. А вы понагружайте денек другой - а потом сравните. Для затравки такие числа
на новом каталоге скорость создания файлов 80 тыс файлов/с
в каталоге который активно использовался, или просто забит (где нить 10 млн файлов) - скорость создания 4 тыс файлов в секунду.Быстрая? ведь правда?
> Вы видели хоть одни бенчи для aged system? вот и все.У меня таких aged system у самого найдется эн штук. Кстати для ext4 есть какие-никакие дефрагеры. Приветы ZFS-у и еще некоторым, если что :).
> (где нить 10 млн файлов)
Все бы ничего. Кроме того что это очень нишевой юзкейс. И лично мне вообще не интересно как оно такое работает - а просто потому что у меня нет таких иерархий.
А для начала, большинство программ элементарно обделаются если им подсунуть диру с 10 млн файлов. Они будут тупить по полчаса, а то и вовсе всю память выжpyт.
> Быстрая? ведь правда?
Внезапно, нагадить можно любой ФС. Забей вон ZFS в хламину, понаделав снапшоты - узнаешь как CoW устраивает вермишель из данных. Изя вон тут конкретно догнался один раз - до 6 мегов на шпиндель.
>> Вы видели хоть одни бенчи для aged system? вот и все.
> У меня таких aged system у самого найдется эн штук. Кстати для
> ext4 есть какие-никакие дефрагеры. Приветы ZFS-у и еще некоторым, если что
> :).не помогает. ссылку выше я показал.
>> (где нить 10 млн файлов)
> Все бы ничего. Кроме того что это очень нишевой юзкейс. И лично
> мне вообще не интересно как оно такое работает - а просто
> потому что у меня нет таких иерархий.
> А для начала, большинство программ элементарно обделаются если им подсунуть диру с
> 10 млн файлов. Они будут тупить по полчаса, а то и
> вовсе всю память выжpyт.mail сервер с imap - очень нишевый?
Выше в ссылке - чувак писал о обычном веб сервере.>> Быстрая? ведь правда?
> Внезапно, нагадить можно любой ФС.да ну? разве?:) ext4 супер fs которой все по зубам :)
Собственно понятно - когда подсунули явные проблемы - так сразу надобности в колбасе нету.
> не помогает. ссылку выше я показал.Оно как бы да. Но вас наверное должны были научить ваши любимые корпорасы что в разработке софта вообще есть такая фигня как приоритеты. И вот конкретно этот случай - очень узконишевой. Поэтому для разработчиков он низкоприоритетный. Вот никто им и не заморачивается, кроме пары утонченных извращенцев на всю планету. И все логично - кому надо экзотику - тот с ней и заморачивается.
> mail сервер с imap - очень нишевый?
Если какой-то сервер валит 10 миллионов файлов в одну диру, без какой либо классификации - ну и кто его авторам и админам вообще доктор? Они что, из эпохи CP/M не вышли и дирами пользоваться не умеют принципиально?
> Выше в ссылке - чувак писал о обычном веб сервере.
На обычных серверах 10М файлов в одну диру не вываливают. И вообще, я бы сто раз подумал до того как пользоваться софтом с таким хранением данных. Потом "в случае чего" будет залет на очень нестандартное приключение. Стоя, в лыжах, в гамаке. В смысле, большинство привычного софта просто облажается сколь-нибудь разумно работать с такой иерархией. На хабре кажется был перец у которого диск забился мелкими файлами и он их стереть не мог - память при попытке стирания rm'ом ... кончалась.
> да ну? разве?:) ext4 супер fs которой все по зубам :)
Ext4 - обычная ФС, достаточно хорошая. Один из неплохих вариантов перепевки "классических" подходов, с обычным журналом, каким-никаким хешированием дир и экстентами и совместимостью с ext3, что дает возможность относительно плавной миграции систем. Назвать шедевром - ну хз. Но - good enough для многих применений. Легкий, шустрый в большинстве обычных ворклоадов.
> Собственно понятно - когда подсунули явные проблемы - так сразу надобности в колбасе нету.
Так вам какую-то странную колбасу надо. Нарезанную на 10 миллионов ломтиков.
все понятно. рассуждения админа локалхоста слабо интересуют.
какой размер у spool серьезного почтовика известно?
в imap мире тоже много всякого.Пример в оригинальном письме - проблемы на хостинге.
Все это очень нишевые случаи ? ведь так ?:) Ладно - продолжайте себя убеждать. На самом деле необходимое условие просто стирать/создавать файлы. После достаточно большого количества - вы в директорию не сможете записать 400 файлов и будете иметь ENOSPC.
ну что ж - когда наступите - не говорите что вас не предупреждали, весь у вас будет тоже нишевый случай.
> все понятно. рассуждения админа локалхоста слабо интересуют.А рассуждения кадров, вываливающих 10М файлов в 1 диру - очень нишевая субстанция, почти на уровне желтого дома, т.к. такие иерархии почти не поддаются администрированию типовыми тулзами.
> какой размер у spool серьезного почтовика известно?
> в imap мире тоже много всякого.Еще раз: если софт валит 10М файлов, без какой либо разбивки по иерархии - это крындец а не софт в плане администрирования. При попытке делать какие либо манипуляции с такой иерархией большинство софта просто встрянет и админ потом чуть ли не пойдет кодить сам отдельную приблуду, дергающую нужные сисколы. Что как-то далеко не лучшее использование времени сисадмина, да и программисты из админов зачастую очень так себе.
> Пример в оригинальном письме - проблемы на хостинге.
Я думаю что проблемы там прежде всего с головой, ну и как следствие с архитектурой софта, если они 10М файлов в 1 диру валят без каких либо субдир. Даже нжинкс почему-то в курсе что воротить такие иерархии не комильфо и умеет структурирование по дирам.
Технически, ты прав: это таки костыли. Как ныне упеченный Рейзер вещал, если вам вообще нужна БД - да вы просто не ту файловую систему используете! Но это в теории. А на практике - у всех ФС есть слабые места. А хорошо работают только типовые юзкейсы, где "вытоптали поляну". А всякие краевые случаи, типа торент-клиента писавшего файл на 10Гб отдельными блоками по 4 кило и потому завалившего все в хлам метаданными и прочие 10М файлов в 1 дире и прочие тома btrfs размером менее гигабайта - это очень нишевые развлечения. И неважно они работают на самом деле потому, что натыкаются на все это попросту полтора человека на всю планету. У остальных просто не возникает таких задач. Этого достаточно чтобы показательно помахать тут в коментах флагом. Но недостаточно для того чтобы кто-то запилил все это. Поэтому такое на самом деле для мало-мальски опытного системщика - "ожидамо" и "предсказуемо" :).
> Все это очень нишевые случаи ? ведь так ?:)
Да, 10М файлов в 1 дире, без разбиения на субдиры - нишевой случай. Потому что этот слчай вообще х-во поддается попыткам администрирования и если кто на него нарвался - там чинить первым делом надо явно не EXT4, а проблемы с головой у тех кто так вообще делает.
> достаточно большого количества - вы в директорию не сможете записать 400
> файлов и будете иметь ENOSPC.Хм, вот это заявление уже интереснее. А какова механика этого процесса (нечто типа фрагментации структур?) и почему это кусает только сильно избранных?
> ну что ж - когда наступите - не говорите что вас не
> предупреждали, весь у вас будет тоже нишевый случай.Вероятность этого - на уровне прилетания метеорита мне в голову. Потому как я им пользуюсь не первый год в самых разных позах. И никаких неожиданностей не возникало. А то что теоретически может - ну, ок, пару человек за десяток лет даже может и зашибает метеоритами. Не очень сильный аргумент за то чтобы в бункере жить. Мне вообще идея делать мегаконфигурации-переростки на 1 мега-машине видится провальной еще на старте. Дофига стартапов показали что будущее - за распределенными системами, где отдельному узлу совершенно не обязательно страдать гигантоманией, работая на пределе возможностей. Вон ext4 - у целого гугеля. Иди расскажи им какие они там лохи? Когда у них даже выгорание плюс-минус пары серверов целиком - не влияет ни на что. Это так, к вопросу о правильной архитектуре больших структур :)
> Вы видели хоть одни бенчи для aged system?Есть терабайтная Ext4 возрастом лет около трёх, забитая разнокалиберным трэшем на 98%. Какие бенчи можно прогнать?
>> Вы видели хоть одни бенчи для aged system?
> Есть терабайтная Ext4 возрастом лет около трёх, забитая разнокалиберным трэшем на 98%.
> Какие бенчи можно прогнать?там больше вопрос как часто в директории создаются и удаляются файлы.
типичный пример - spool директория у почтовика, там должно быть заметна разница в создании файлов по сравнению с новосозданной директорией
>> Вы видели хоть одни бенчи для aged system?
> Есть терабайтная Ext4 возрастом лет около трёх, забитая разнокалиберным трэшем на 98%.
> Какие бенчи можно прогнать?Есть 7Тб раздел на ext4, свободно 300гб, лежит на 50 рейде (dell percent) из 6х2тб дисков, более 2лет.
На двух дисках есть бед блоки, и пара файлов не читается, смонтирована с errors remount ro.
В dmesg при попытке чтения этих файлов сыпятся ошибки, но в ридонли не переходит
> тормоза в каталоге после длительного создания/удаления файловА можно поподробнее ? у меня как раз ext4 (на домашнем компе уже несколько лет), может какая новая инфа будет полезна в плане оптимизации
Там бага в дизайне ext{3/4} hashed tree. dx_node только создается - но никогда не удаляется. В результате дерево будет забито совершено не нужными элементами, что скорее ухудшит время поиска чем улучшит.
в некоторых случаях после этого в каталоге можно будет разместить только 4 файла (если нарваться на коллизии в хэше).поэтому переодически появляются топики типа такого - http://www.spinics.net/lists/linux-ext4/msg47866.html
а смотря последние правки в e2fsprog - хочется спросить у маинтейнера ext4 - чем ты собака думал когда принимал код от индуса в котором нет вообще никаких обработок ошибок, в результате чего последние версии e2fsck падают если квотный файл поврежден и не могут вылечить FS.
> котором нет вообще никаких обработок ошибок, в результате чего последние версии
> e2fsck падают если квотный файл поврежден и не могут вылечить FS.Угу, вспомнился чувак с лисяры, поднимавший ZFS хексэдитором. Оказывается, энтерпрайзники то тоже индусский код не допускающий мысль о том что может быть read error принимают.
>> котором нет вообще никаких обработок ошибок, в результате чего последние версии
>> e2fsck падают если квотный файл поврежден и не могут вылечить FS.
> Угу, вспомнился чувак с лисяры, поднимавший ZFS хексэдитором. Оказывается, энтерпрайзники
> то тоже индусский код не допускающий мысль о том что может
> быть read error принимают.zdb есть, если что.
>> При этом, если правильно помню
>> рассказ led@ времён создания CONFIG_EXT4_USE_FOR_EXT23, ext4.ko как замена ext3.ko ещё
>> и оптимальней может быть на той же ФС.
> оптимальней только за счет прозрачного включения фичей от ext4.Нет. Драйвер ext4 быстрее работает на ext3, чем первоначальный драйвер ext3. Без включения расширений ext4. Просто сам драйвер ext4 переписывали фактически заново и некоторые моменты сделали более оптимально.
Так что действительно держать отдельный драйвер ext3 имело смысл только пока драйвер ext4 не стал стабильным.
>>> При этом, если правильно помню
>>> рассказ led@ времён создания CONFIG_EXT4_USE_FOR_EXT23, ext4.ko как замена ext3.ko ещё
>>> и оптимальней может быть на той же ФС.
>> оптимальней только за счет прозрачного включения фичей от ext4.
> Нет. Драйвер ext4 быстрее работает на ext3, чем первоначальный драйвер ext3. Без
> включения расширений ext4. Просто сам драйвер ext4 переписывали фактически заново и
> некоторые моменты сделали более оптимально.давайте без сказок? сходите на Bull что ли.. или в публикации Alex Tomas aka bzzz. За одно поймете откуда появилась ext4 и почему.
> So it is possible to remove ext2 and ext3 without breaking existing users or preventing them from going back to older implementations. Beyond that, mounting an ext2/3 filesystem under ext4 allows the system to use a number of performance enhancing techniques - like delayed allocation - which do not exist in the older implementations. In other words, ext4 can replace ext2 and ext3, maintain compatibility, and make things faster at the same time. Given that, one might wonder why removing the older code even requires discussion.http://lwn.net/Articles/426961/?format=printable
> сходите на Bull что ли.. или в публикации Alex Tomas aka bzzz.
Ссылку в студию!
> За одно поймете откуда появилась ext4 и почему.
Я помню те дебаты, как долго отказывали Рейзеру в принятии кода - ссылаясь на нестабильность и чуть позже начали развивать нестабильную и экспериментальную ext4 прямо в ядре.
Тогда же и обсуждалось, что можно улучшить производительность ext3 за счет использования новой кодовой базы ext4.
> Я помню те дебаты, как долго отказывали Рейзеру в принятии кода - ссылаясь на нестабильность и чуть позже начали развивать нестабильную и экспериментальную ext4 прямо в ядре.До того как ext4 влили в ядро она (основные патчи) 3 года крутилось на машинках TOP10.
http://www.bullopensource.org
дальше гуглить ldiskfs2 cfs Alex Tomas
> До того как ext4 влили в ядро она (основные патчи) 3 года крутилось на машинках TOP10.Конкретная ссылка/цитата есть с датами?
Насколько я знаю, ext4 сразу же развивали в основной ветке ядра под названием ext4dev - linux-2.6.19 Released 29 November, 2006
http://kernelnewbies.org/Linux_2_6_19Позже (2.6.28) переименовали в ext4 - посчитали что она стабильна. Рейзера же с уже готовой фс не пропустили (даже как экспериментальную версию), нервы у него сдали и чем кончилось все знают.
cvs.lustre.org уже давно в down. посему линк на ldiskfs2 дать не могу.
mballoc, экстенты. uninit groups, и что-то еще пришло оттуда.
патчи были сделаны
A40192a06|alex|<remote>|lustre/kernel_patches/patches|1.1|ext3-mballoc-2.4.24.patchчто такое lustre.org - думаю вам известно.
кто такой Alex Tomas, Andreas Dilger и как он относится к ext3/ext4 - думаю стоит погуглить.
так что вам известно очень мало.
> mballoc, экстенты. uninit groups, и что-то еще пришло оттуда.Несколько кастомных патчей для ext3 != ext4. Для стабилизации и доведение всего этого до состояния пригодного на серверах ушло два года. Все это пилилось в основной ветке, а не в отдельной экспериментальной.
> так что вам известно очень мало.
Вполне достаточно, чтобы понять, что на тот момент код был сырой.
А теперь старый драйвер ext3 медленнее драйвера ext4 при работе с ext3.
>> mballoc, экстенты. uninit groups, и что-то еще пришло оттуда.
> Несколько кастомных патчей для ext3 != ext4. Для стабилизации и доведение всего
> этого до состояния пригодного на серверах ушло два года. Все это
> пилилось в основной ветке, а не в отдельной экспериментальной.несколько кастомных патчей дают 80% отличия ext3 от ext4.
>> так что вам известно очень мало.
> Вполне достаточно, чтобы понять, что на тот момент код был сырой.Скажите это Cray и LLNL.. а то они были не в курсе и использовали этот код много лет.
> несколько кастомных патчей дают 80% отличия ext3 от ext4.Умка, может быть ты не в курсе про принцип 20/80? Остальные 20% работы и требовали 80% въе, при том без этих 20% - левые патчи даром никому кроме вас и не вперлись. Прикинь какая проза жизни?! :P.
> Скажите это Cray и LLNL.. а то они были не в курсе
> и использовали этот код много лет.Да и хрен бы с ними. Мало ли кто, что и где патчит.
зачем же тогда так устойчиво эти патчи приняли в ядро ?:) может они таки не левые ?прикинь какая проза жизни :) патчи левые но их почему-то тянут в ядро..
> зачем же тогда так устойчиво эти патчи приняли в ядро ?:) может
> они таки не левые ?Патчи не левые только после того как их ACKнули и закоммитили. И до этого момента могут пять и даже 10 раз послать курить бамбук и попросить все переделать на...й.
> прикинь какая проза жизни :) патчи левые но их почему-то тянут в ядро..
Ты так говоришь, как будто разработчики с топором бегали за авторами патчей, обещая их зарубить если патчи не дадут.
иногда бегают. Прикинь :)кроме ядра вспоминается история с object-c и gcc - когда за apple бегали и требовали переделать их патчи на новый gcc под gpl v3, а apple говорило что взяло по gpl v2 - и вернет по gpl v2.
А крику то сколько было..
а кстати hashed directory появившиеся в ext3 и допиленные в ext4 - тоже оттуда пришли.А с Рейзером все было совсем иначе (имя в близких контактах почти весь namesys) я могу точнее знать, чем вы.
> А с Рейзером все было совсем иначе (имя в близких контактах почти
> весь namesys) я могу точнее знать, чем вы.Расскажите вашу версию.
>> А с Рейзером все было совсем иначе (имя в близких контактах почти
>> весь namesys) я могу точнее знать, чем вы.
> Расскажите вашу версию.Зачем? вы же и так все знаете :) лучше расскажите нам откуда в ext4 появился multi block allocator, экстенты (изначально размещавшиеся в EA), hashed directory, uninit groups и прочее что так хорошо отличает ext4 от ext3.
> Зачем? вы же и так все знаете :) лучше расскажите нам откуда
> в ext4 появился multi block allocator, экстенты (изначально размещавшиеся в EA),
> hashed directory, uninit groups и прочее что так хорошо отличает ext4 от ext3.Это все замечательно. Но сказать что это какие-то мега-уникальные технологии... ээээ... на момент появления EXT4 в майнлайне все это уже умели JFS, XFS, Reiser и прочие.
Ext4 - совершенно заурядная файлуха в плане устройства. И единственное ее реальное преимущество относительно остальных - обратная совместимость с EXT3, что обеспечило плавность миграции (и отсутствие половины преимуществ, ибо том мигрировавший с EXT3 не имеет экстентов поначалу).
>> Зачем? вы же и так все знаете :) лучше расскажите нам откуда
>> в ext4 появился multi block allocator, экстенты (изначально размещавшиеся в EA),
>> hashed directory, uninit groups и прочее что так хорошо отличает ext4 от ext3.
> Это все замечательно. Но сказать что это какие-то мега-уникальные технологии... ээээ...
> на момент появления EXT4 в майнлайне все это уже умели JFS,
> XFS, Reiser и прочие.разговор не о том :) разговор лишь о том кто и какой вклад внес в то что бы ext3 переименовали в ext4.
А совместимость.. краю совсем не упало форматировать все кластера при обновлении )
> разговор не о том :) разговор лишь о том кто и какой
> вклад внес в то что бы ext3 переименовали в ext4.Судя по коммитам - вклад там много кто и куда вносил. А так вон у Криса Мэйсона тоже core part дизайна вроде его. Но поначалу это был стремный глюкастик, ловящий oops при обычном удалении файла mc. Кому он был бы такой нужен? Да никому! А потом на это навалилась толпа народа, допиливющих и обезглючивающих. И вот вчерашний глюкастик уже вполне работает. И даже держит на плаву сервера мордокниги. Припишем все Мэйсону? Не, так не пойдет. Это въе... вон той толпы народа превратило глюкастика в нечто юзабельное. А от Мэйсона - core part дизайна. Важная и нужная штука. Но не 100% работы. И без тех 20% доведения до ума - эти 80% никому даром не упали бы.
> А совместимость.. краю совсем не упало форматировать все кластера при обновлении )
И тем не менее, кроме EXT я так навскидку еще btrfs помню из позволяющих последовательный апгрейд на более навороченную ФС. Еще до некоторой степени ZFS, но он как-то весьма нишевая штука. Ну и мне не нравится что сани вместо решения сложных инженерных проблем вытягивали это громким маркетинговым булшитом.
> Давно пора. Можно ещё и JFS с ReiserFS выкинуть,Эй, полегче на поворотах. JFS - неплохой выбор для систем с хилым процом. Ну и загибаться не склонен, при любых издевательствах.
А в случае ext3 - выкинули именно драйвер EXT3. Потому что EXT3 - subset EXT4 и цепляется как "этакий обкоцаный по фичам EXT4" драйвером EXT4. То-есть, файловые системы EXT3 - работать не перестанут :).
JFS по надёжности хуже Ext4.
> JFS по надёжности хуже Ext4.Очень спорный тезис. Держал эн томов в оном, пока его неспешность не задолбала. Никаких проблем с надежностью не заметил. В пределах умений обычной классической файлухи с журналом только метаданных - вполне на уровне.
Мне он не понравился в основном тем, что если проц не супер-тормозливый и работа с ФС упирается не в проц - тогда JFS работает неторопливо по сравнению с другими. И ничего этакого взамен не умеет. Ну и смысл в нем в результате? В общем файлуха для тех кому хочется файло отгружать с древнего хилого роутера какого-нибудь.
Откуда такие данные? Есть пруф?
> JFS по надёжности хуже Ext4.Насколько знаю, это не так.
> JFS ... не склонен, при любых издевательствах.Есть пруф?
>ReiserFSТебе дорогу через лес указать? Я везде ставлю систему на ReiserFS v3.6.
Ты можешь и пневмонию гомеопатией "лечить", но когда это поощрялось в обществе разумных людей?
> Тебе дорогу через лес указать? Я везде ставлю систему на ReiserFS v3.6.Так тебе и надо. Особенно весело будет если сбацать пару виртуалок с рейзером и положить их на диск с рейзером. А потом придет fsck и укатает тебе дерево из виртуалки прямо на основной том. Что дальше будет с ФС - я думаю ты понял.
A ext2?
убейтесь об стенку
> убейтесь об стенкуправильно, давайте я еще в добавок толкну.
ext2 на embedded и flash системах распространен. разница ext2 и ext3 большая(один пример:одна не журналируется а другая журналируется) и потому ext3 не покрывает возможности ext2
Всегда можно выключить журнал
> ext2 на embedded и flash системах распространен.Вот врать только не надо, или ламерить. EXT2 для флеша - даром не упал. Для этого более специализированые ФС рулят. А для эмбедовки EXT2 вообще смерти подобен - файлуха без журнала, которой при крахе надо fsck на полчаса гонять - вообще звиздец.
> разница ext2 и ext3 большая
Огромная. В ext3 есть журнал, а ext2 - нет. Кроме всего прочего, если ext3 отпилить журнал, получится ext2. На самом деле там еще некие опции типа HTree добавили, так что можно получить и странноватый гибрид, где нет жунала (как и в ext2) но есть HTree(которого в изначальном варианте ext2 не было). Чем считать такой гибрид - даже и не знаю. Но так можно.
ext2 нужен для бута, так как журналирование не к чему
> ext2 нужен для бута, так как журналирование не к чемуext4 уже давно может быть без журнала.
Но её избыточность на разделе в 100М нафиг не впёрлась, на SD и USB флешках тоже.
SD ненужен из-за DRM, для USB есть F2FS
> SD ненужен из-за DRM,Нынче многие эмбедовочные платы грузятся с SDшек. У них протокол прост как три копейки и они достаточно емкие.
> для USB есть F2FS
...только usb в бутлоадере раскочегаривать слегонца напряжно и довольно глючно.
>Нынче многие эмбедовочные платы грузятся с SDшек.Вместо CFast взяли какое-то кю.
> ext2 нужен для бута,Какого еще бута? Ботинком по затылку чтоли? Иные загрузчики умеют грузиться не то что с EXT4, но и даже с btrfs какого-нибудь.
Для бута щас EFI раздел на FAT32 же
Атак ли надо удалять ext3? Он что - сильно мешает? Насколько помню, корневой раздел ext3 признан самым стабильным в отличие от ext4. Прежде, чем удалять, неплохо бы сначала допилить и доработать ext4.
Признан кем?
Анонимными икспердами, как обычно.
драйвер ext4 - полностью умеет работать с ext3 и ext2.
ты еще перепиши текст из статьи - там вообще то об этом сказано. Просто те кто комментировал тут, походу не умеют читать и понимать текст.
> Атак ли надо удалять ext3? Он что - сильно мешает?Так удалили только сам драйвер ext3. А файлухи в этом формате будут цепляться драйвером EXT4.
> Насколько помню, корневой раздел ext3 признан самым стабильным в отличие от ext4.
Да что там, FAT12 всем по стабильности покажет фак - он совсем уж протух, не то что EXT3. Держите корневые разделы на FAT12. На флопарях. Вот тогда будет конкретный стабилизец.
> Прежде, чем удалять, неплохо бы сначала допилить и доработать ext4.
Прежде чем вякать - неплохо бы хотя-бы минимально разобраться в вопросе.
эту проблему давно решили и ext4 может быть смело быть рутовым разделом
>Атак ли надо удалять ext3? Он что - сильно мешает?два руля два крыла(с)
это посути одно и тоже ток крылья шире..
предлагаю разработчикам из компании SUSE поставить себе виндовс и не трогать ext3
Ядро все стерпит? Больше легаси для бога легаси?
Предлагаю тебе нормально прочитать новость перед тем как писать комментарии.
Дык и ext4 уже устарела, вон в RHEL 7 по умолчанию xfs, а ext4 является допустимой, но не рекомендованной.
> Дык и ext4 уже устарела, вон в RHEL 7 по умолчанию xfs,
> а ext4 является допустимой, но не рекомендованной.RedHat купил разработчиков xfs, а разработчиков ext4 купить нельзя - их просто нет.
поэтому что бы не мучаться и иметь свою поддерживаемую FS - перекинули всех на xfs.
> RedHat купил разработчиков xfs, а разработчиков ext4 купить нельзя - их просто нет.А Теодор Тсо куда делся, например? oO Другое дело что он IIRC в гугеле работает - купить его будет весьма нелегко :).
>> RedHat купил разработчиков xfs, а разработчиков ext4 купить нельзя - их просто нет.
> А Теодор Тсо куда делся, например? oO Другое дело что он IIRC
> в гугеле работает - купить его будет весьма нелегко :).Этот чудак уже давно ничего крупного в ext4 не комитит. шифрование разделов сделал не он, project quota - не он. Он уже давно уже просто маинтайнер - причем хреновый.
принять такой код
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/qu...
мог только чудак на букву М... - который не смотрит на обработку ошибок.Ошибка чтения блока - не повод что бы не пытаться разобраться в том что прочитали.
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/qu...
выход за пределы номера блока - это не повод что бы не начинать дальше парисить прочтение.Хочется спросить - этого Теодора вообще учили как правильно писать код? что обработка ошибок должна быть.. ну там хоть чуть чуть.. не?.. не учили?.. и сам не смог научиться..
В результате имеем не возможность починить FS в случае если повреждены квоты, или собираем с disable-quota руками или имеем ext4 раздел который починить не возможно.
Офигенный маинтейнер - это не считая разных других ляпов по мелочи.
ах да, изначально там были аналоги BUG_ON() с exit(2). Но потом очередной патч китайца/индуса вынес это - а обработки ошибок не добавил.
> Офигенный маинтейнер - это не считая разных других ляпов по мелочи.Да-да, как таких только земля держит? А ещё доверили ему, понимаешь, ext (которые он сам же и разработал), доверили подсистему ГПСЧ в ядре... Надо было анонима туда, вот он бы показал всем, как надо принимать код, правда?
А ты считаешь нормальным забагованый код? Надо же...
> А ты считаешь нормальным забагованый код? Надо же...Нет же, он считает что ты не имеешь права раскрывать рот, вместо коммита!
> Да-да, как таких только земля держит?стареет. Нюх уже не тот. Советую ознакомиться с последними changelog по ext4.
> Надо было анонима туда, вот он бы показал всем, как надо принимать код, правда?
Мне хватает своих проблем и инспекций. И в коде ext4 / утилит тоже.
Но не разу не проходил код без проверки на ошибки.Хотя когда Шигорин сказал что проверка на компиляцию это шедевр ведения проекта.
И принимаемый код не обязан компилироваться.. До таких перлов ext4 далеко, хотя уже были ситуации когда выпускали быстрый фикс в stable ветке - а ядро переставало компилироваться.
> Хотя когда Шигорин сказал что проверка на компиляцию это шедевр ведения проекта.Можно ссылочку или сразу извинитесь?
>> Хотя когда Шигорин сказал что проверка на компиляцию это шедевр ведения проекта.
> Можно ссылочку или сразу извинитесь?помните обсуждение OpenVZ? как вы там сказали на счет сборки и запуска unit тестов на каждый комит?
Конкретную ссылку - думаю сами найдете.
Ты уже переобулся, а ссылки так и не предоставил.
> Этот чудак уже давно ничего крупного в ext4 не комитит.Торвальдс тоже давно уже не основной коммитер ядра. А ядро почему-то считается "его" в плане области ответственности :)
> шифрование разделов сделал не он, project quota - не он.
Так, уже интереснее. Так разработчиков все-таки у нас сколько? Фичи возникли в вакууме? Или таки их разработчики писали? И стало быть их было не ноль? :)
...
Ноль программистов ругал сердитый шеф
Потом уволил одного - и стало их FF> Он уже давно уже просто маинтайнер - причем хреновый.
Майнтайнер как майнтайнер.
> Ошибка чтения блока - не повод что бы не пытаться разобраться в
> том что прочитали.Прикольная логика. Всерьез предлагается парсить мусор?
> или собираем с disable-quota руками или имеем ext4 раздел который починить
> не возможно.
> Офигенный маинтейнер - это не считая разных других ляпов по мелочи.На фоне мужика с хексэдитором на лисяре то - он еще зеленый нуб и ему до саночников и их маркетингового булшита еще учиться и учиться.
> Прикольная логика. Всерьез предлагается парсить мусор?read_blk(dquot->dq_h, blk, buf);
if (depth == QT_TREEDEPTH - 1) {
for (i = 0; i < QT_BLKSIZE >> 2; i++) {
blk = ext2fs_le32_to_cpu(ref[i]);
check_reference(dquot->dq_h, blk);
if (blk && !get_bit(bitmap, blk))
entries += report_block(dquot, blk, bitmap,
process_dquot, data);
}...
static void read_blk(struct quota_handle *h, unsigned int blk, dqbuf_t buf)
{
int err;err = h->e2fs_read(&h->qh_qf, blk << QT_BLKSIZE_BITS, buf,
QT_BLKSIZE);
if (err < 0)
log_err("Cannot read block %u: %s", blk, strerror(errno));
else if (err != QT_BLKSIZE)
memset(buf + err, 0, QT_BLKSIZE - err);
}как легко заметить read_blk может таки иметь ошибку (log_err только ругнется в консоль или syslog).
но это не мешает продолжать парсить прочитаное. Тоже самое относится к check_reference - которое проверяет индекс блока на валидность.. куда-то репортим об этом. реакции 0.Вопрос - кем должен быть человек пропустивший такой код?
пример паденияe2fsck -f /dev/md0
Pass 5: Checking group summary information
[ERROR] quotaio_tree.c:590:check_reference:: Illegal reference (2711113728 >= 17) in user quota file. Quota file is probably corrupted.
Please run e2fsck (8) to fix it.
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x149e4110
e2fsck[0x42d26e]
/lib64/libc.so.6(+0x326b0)[0x7f98710816b0]
e2fsck[0x4303c8]
e2fsck[0x4302fd]
e2fsck[0x4302fd]
e2fsck[0x4302fd]
e2fsck(qtree_scan_dquots+0x7a)[0x43065a]
e2fsck(quota_compare_and_update+0xb2)[0x42dc92]
e2fsck(main+0x2279)[0x40db59]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f987106dd5d]
e2fsck[0x409c09]все.. приплыли - больше вы починить ext4 не можете.
Правда умный человек пропустил такой код?
Ещё занятнее поведение драйверов популярных файловых систем при порче метаданных.
> Ещё занятнее поведение драйверов популярных файловых систем при порче метаданных.Так это у всех так - вон в ZFS перец вручную транзакцию откатывал. Потому что механика ФС, деланная в допущении о сферическом отсутствии read error в вакууме оказалась не готова к тому что всиретится бэд. Потом, конечно, это костыльнули, но как видишь, принцип тот же самый...
ах вот почему по умолчанию у Красной Шапочки xfs :) я чет пропустил их сделку :) вроде как Silicon Graphics на банкротство подавало и все такое...
не обязательно покупать кусок SGI.
достаточно перекупить девелоперов.
> вроде как Silicon Graphics на банкротство подавало и все такое...Современные мейнтейнеры xfs не имеют отношения к Silicon Graphics.
> Современные мейнтейнеры xfs не имеют отношения к Silicon Graphics.ну это ясен, как красный перец :) код самой файловой системы xfs в ветке ядра находится и дорабатываются, а вот userspace утилиты для xfs на SGI ресурсе
Как страшно жить!
EXT3 выпиливают, systemD запиливают...
Когда ж ты то выпилишься?
Не так.
Чувак, ты не поверишь, но ты тебя тоже выпилят, и сравнительно скоро.
> Как страшно жить!
> EXT3 выпиливают, systemD запиливают...Будь мужиком - грузи древний бояздэ с флопаря.
правильно, зачем дублирующий код, когда ext4 заменяемый для ext3. несколько сотен, а может тысяч строк кода удалится из того быстрорастущего ядра
Все удалить и заново переписать, я так часто делаю
Покажи своё ядро.
ZFS, говорите...
А почему никто btrfs не вспомнил?
Прежде чем хвалить этот ход сперва добейтесь.
Те кто не делал своё ядро не имеют право хвалить чужое.
> Прежде чем хвалить этот ход сперва добейтесь.
> Те кто не делал своё ядро не имеют право хвалить чужое.По такой логике - сказать что конфета вкусная это вообще кощунство просто. Ведь я не кондитер...
Где ты был 5 лет назад, когда на линукс-форумах это был главный аргумент.
> Где ты был 5 лет назад, когда на линукс-форумах это был главный аргумент.Здесь же и был, имхо.
Вот это пук!
А ничего, что вы, не будучи курицей, несущей яйца, можете определить: вкусная яичница или нет?