Эдуард Шишкин выступил с критикой Btrfs

> А есть графики зависимости процента занимаемого метаданными от размера раздела и размера файлов/количества файлов его заполняющих?

Возьми да построй, делов-то. Вот только что это тебе даст?

ИМХО Без этого некорректно наезжать на ФС.

Ага, в ФС есть фундаментальная проблема, но без набора графиков она проблемой не считается чтоли? Самому не смешно?

маил-сервер, исходники дальше придумай сам.

По теме: Одного теста с разделом, мягко говоря, не типичного размера недостаточно для каких-либо выводов, но проблема есть, её нужно решать.

> Аргументы «годности»? Я их тут не вижу.

А я не вижу аргументов в пользу 4.2. Так чта..

Пользуюсь ext4. Вообще на reiser4 тоже интересно взглянуть. Но мне прежде всего стабильность.

Мне на ext4 хорошо.;-) Но если за несколько месяцев не построили это ни о чем не говорит?;-)

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

задолбало. выключил и сделал dd if=/dev/zero of=/dev/sdb2

но успел заметить, что четырёхметровых файлов на 8 гигов жрут чуть больше 9 гигов, т.е. уже не так существенно.

Ну предположим метаданные занимают много места при разделах меньше N или при заполнение маленькими файлами.

в толксы анонимуса всё равно не пустят

Потому что рейзер нужен для кучи мелких файлов. Разве что под корень, да и то с натяжкой. Скоро корень все перенесут на SSD, и скорость рейзера потеряет всякую актуальность. А btrfs - система для всех, на нее можно будет и корень воткнуть, и хому, и файлопомойку

> А btrfs - система для всех

Пруф?

Только мне кажется, что новость положительная? Лично я буду рад как стабилизации btrfs, так и принтию Riser4 в vanilla.

> А btrfs - система для всех, на нее можно будет и корень воткнуть, и хому, и файлопомойку

Вот только до этого еще довольно далеко, если примитивный тест вскрывает такие вещи. А что будет, если начать всякие продвинутые вещи типа снимков и клонов (надо же было такой корявый термин придумать - subvolume)? Какие сурпризы нас там ждут?

Новость неплохая. Просто она о споре между двумя группами хороших людей.;-)

> Мы все знаем что твоя личная неприязнь аргументом не является, ни разу

Мы? Мы знаем, что моя личная неприязнь - это твоя выдумка. :)

> маил-сервер, исходники дальше придумай сам.

По теме: Одного теста с разделом, мягко говоря, не типичного размера недостаточно для каких-либо выводов, но проблема есть, её нужно решать.

Проблема наверное, есть, ога. И может быть даже ее нужно решать. Но вообще, не очевидно, что хранить куски данных размером меньше физического сектора (или может даже размера страницы) и в большом количестве в виде отдельных файлов — это хорошая идея.

> Только мне кажется, что новость положительная?

Ну то, что Шишкин оказался в RedHat - это неплохо, во всяком случае, должно быть, как минимум, для него самого.

Лично я буду рад как стабилизации btrfs, так и принтию Riser4 в vanilla.

Пора уже не только о запихивании нового, но и о выкидывании старого думать. А то сколько там файловых систем разных в линаксе? 64?

> Вроде бы Линусу жена строго-настрого запретила reiser4 в мейнстрим включать

она что, тоже лезет в бизнес мужа? Одной из претензий к жене Ганса были махинации с бухгалтерией его компании...

> Проблема наверное, есть, ога. И может быть даже ее нужно решать. Но вообще, не очевидно, что хранить куски данных размером меньше физического сектора (или может даже размера страницы) и в большом количестве в виде отдельных файлов — это хорошая идея.

Ну наиболее распространенный размер физического сектора пока 512 байт, 4 КБ станут мэйнстримом еще даже не в этом году и даже не в следующем. А так твои бы слова да богу в уши. К сожалению, объективная реальность такова, что хранение мелких кусков данных в виде отдельных файлов встречается не так уж редко.

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

> Но вообще, не очевидно, что хранить куски данных размером меньше физического сектора (или может даже размера страницы) и в большом количестве в виде отдельных файлов — это хорошая идея.

Не то слово. Я с этим познакомился ещё в DOS. Была игрушка, меньше дискеты занимала, но на неё не лезла, потому что состояла из туевой хучи файлов длиной байт по 15. :)

Пора уже не только о запихивании нового, но и о выкидывании старого думать. А то сколько там файловых систем разных в линаксе? 64?

И сколько, если не скерет, в ядре Linux стабильных файловых систем общего назначения? ext2/3, ext4, ещё с небольшой натяжкой xfs и jfs (которые нельзя использовать в продакшн). Всё? Про функционал этих фс по сравнению с btrfs и riser4 я молчу.

> Ну наиболее распространенный размер физического сектора пока 512 байт, 4 КБ станут мэйнстримом еще даже не в этом году и даже не в следующем.

Глубоко думать мне сейчас лениво, а на первый взгляд мне кажется, что размер страницы в данном случае важнее. В конце концов, весь io через page cache идет только целыми страницами. А если уж идти мимо кэша, то тем более важно правильно продумать формат хранения данных.

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

Так она и справляется, ога. Вопрос лишь в том, насколько хорошо. Ну и кроме того, как я понял из дискуссии, Мейсон считает что в данном случае проблема в тонкой настройке разбиения/склеивания листьев, а не в архитектурных ошибках. Так что пофиксят, куда денутся.

> И сколько, если не скерет, в ядре Linux стабильных файловых систем общего назначения? ext2/3, ext4, ещё с небольшой натяжкой xfs и jfs (которые нельзя использовать в продакшн). Всё? Про функционал этих фс по сравнению с btrfs и riser4 я молчу.

По мне так вообще ни одной. Btrfs имеет шансы таковой стать, но еще но скоро. ZFS пока как ФС использовать нельзя - соответствующий уровень (ZPL) не портирован. Остается только FUSE-ZFS, но это уже не в линакс, который, как известно, ядро.

Вместо этого несколько десятков всякого барахла. Жалкое зрелище..

> Не то слово. Я с этим познакомился ещё в DOS. Была игрушка, меньше дискеты занимала, но на неё не лезла, потому что состояла из туевой хучи файлов длиной байт по 15. :)

Даже во времена ДОСа были архиваторы. В таких случаях они выручали.

Вместо этого несколько десятков всякого барахла. Жалкое зрелище..

Хотя бы одно такое барахло общего назначения назови.

> ещё с небольшой натяжкой xfs и jfs (которые нельзя использовать в продакшн).

Фигасе. А в SGI и не знают, что IRIX нельзя использовать в продакшене...

Здесь речь про Linux вообще-то.

> Здесь речь про Linux вообще-то.

Здесь речь про XFS вообще-то.

Здесь речь про XFS вообще-то.

Ты мне будешь рассказывать, паро что я писал? Прочитай о чём речь в топике.

> Так она и справляется, ога. Вопрос лишь в том, насколько хорошо.

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

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

Может быть. Даже уже что-то пофиксили, и вместо 59 тысяч на разделе в 659MiB получилось создать 106 тысяч на разделе в 1GiB, что вряд ли можно рассматривать как существенное улучшение, принимая во внимание больший размер раздела. Умиляет, как Крис ссылается на то, что без дупликации метаданных их было бы всего 417MiB, то есть всего-лишь 40% от имеющегося пространства. И что про резерв для защиты от ENOMEM не надо забывать.

ZFS вон в те же 659MiB 284 тычячи смогла упаковать, и это с дупликацией метаданных и местом для функциониования CoW.

>>>>> ещё с небольшой натяжкой xfs и jfs (которые нельзя использовать в продакшн).

Фигасе. А в SGI и не знают, что IRIX нельзя использовать в продакшене...

Здесь речь про Linux вообще-то.

Здесь речь про XFS вообще-то.

Ты мне будешь рассказывать, паро что я писал? Прочитай о чём речь в топике.

То есть правильно ли я понимаю, что в IRIX можно использовать XFS в продакшене, а в линуксе – нельзя, да?

Я не знаком с реализацией драйвера XFS в IRIX

>>Вместо этого несколько десятков всякого барахла. Жалкое зрелище..

Хотя бы одно такое барахло общего назначения назови.

Да все что ты выше перечислил как стабильное и почти стабильное. Но это барахло с _моей_ точки зрения. Ты, очевидно, так не считаешь, и прав по-своему.

> ENOMEM

тьфу, ENOSPC конечно же.

Да все что ты выше перечислил как стабильное и почти стабильное. Но это барахло с _моей_ точки зрения. Ты, очевидно, так не считаешь, и прав по-своему.

Я считаю, все эти файловые системы нужны.

>> Так она и справляется, ога. Вопрос лишь в том, насколько хорошо.

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

ZFS вон в те же 659MiB 284 тычячи смогла упаковать, и это с дупликацией метаданных и местом для функциониования CoW.

Дыг это вопрос выбора приоритетов оптимизации.

Вот если, когда btrfs объявят стабильной, она будет проигрывать zfs не только в плотности упаковки мелких файлов, но и во всем остальном, то это будет печально, да. А если она будет в упаковке проигрывать, а в чем-то выигрывать, то может оно того и стоит. Кэп просил передать, что пойнт в том, что упаковка мелких файлов – далеко не самое важное в 2010 году.

>>Да все что ты выше перечислил как стабильное и почти стабильное. Но это барахло с _моей_ точки зрения. Ты, очевидно, так не считаешь, и прав по-своему.

Я считаю, все эти файловые системы нужны.

Я этого не берусь отрицать, по меньшей мере в отношении половины из имеющегося количества в 64 или сколько там. Однако нужность не делает их менее барахлянскими с _моей_ точки зрения.

> Я не знаком с реализацией драйвера XFS в IRIX

Смысл в том, что в отличие от JFS, версия XFS для Linux отличается от изначальной версии для IRIX минимально, AFAIK.

> Кэп просил передать, что пойнт в том, что упаковка мелких файлов – далеко не самое важное в 2010 году.

Старпом просил передать, что в 2010 году ZFS уже как минимум 4 года как широко доступна и используется в продуктиве, тогда как btrfs еще даже из пеленок не вылезла. И то, что далеко не самое важное для Кэпа, может оказаться весьма важным для старпома или адмирала. Плюс проигрывать можно по-разному - можно в пределах погрешности измерений, можно на порядок-другой.

И если уж на то пошло, что самое важное для файловой системы в 2010 году?

И зачем вам на обычных компьютерах все эти замысловатые ФС? Чем ext4 не устраивает?

> он бы еще на 100 Мб раздел сделал ) чтобы служебная информация занимала все 100%

хотя бы тред разрабов почитала что ли, перед тем как глупость сморозить... после патча, который накатал Крис (разработчик btrfs), получалось, что на 1Т раздел влазило *ВСЕГО* 200G двухкилобайтных файлов, т.е. ситуация практически не изменилась:

«I must admit that only getting 200GB of 2kB files into a formatted 1GB partition before it says ENOSPC - and that's after Chris's recent tweak - is a bit disappointing.»

насколько можно было понять по ответам из треда, разработчик brtfs мало понимает что он делает, что вообще происходит, в чем проблема и (тем более) как ее исправить, о чем ему и пишет Эдуард, спрашивая, *ЕСТЬ ЛИ ВООБЩЕ* в природе какие-либо вменяемые бумаги, описывающие используемые в btrfs алгоритмы. Крис либо отшучивается, либо включает дурачка.

> Проблема наверное, есть, ога. И может быть даже ее нужно решать. Но вообще, не очевидно, что хранить куски данных размером меньше физического сектора (или может даже размера страницы) и в большом количестве в виде отдельных файлов — это хорошая идея.

Вот что пишут про это в треде разработчиков:

«I must admit that only getting 200GB of 2kB files into a formatted 1GB partition before it says ENOSPC - and that's after Chris's recent tweak - is a bit disappointing. A little over 50% loss for 2kB files is quite reasonable - most filesystems would do that just due to padding to the next 4kB (the block size), and about 50% wastage in a B-tree is fair enough (at least if there is no sane pattern to the file's creation), as guaranteeing higher utilisation has a performance penalty. But with the delayed allocation, I'd hope for better packing than the worst case, and I'd expect even the worst case to be better than 20% available for data.

Losing 80% of the space to utilisation loss and metadata duplication is disappointing (to me), and a bit suprising, given that one of the purposes of inline extents is to pack small files more efficiently than if they were padded to the block size.»

Т.е. в принципе, потеря порядка 50% места на метаданные в ФС данного типа - можно было бы считать нормой, однако потеря *80%* - причем, после патча от разработчика - уже перебор и полный конец обеда. Тушите свет. Кина не будет - электричество кончилось.

valich * (24.06.2010 22:54:42)

Несмотря.

Только сейчас понял, как полезны были для меня последние два года упорного чтения каментов на ЛОРе. Я в совершенстве овладел исскуством родной речи!

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

=)

у вопящих тут «Reiser4 - наше всё» хочется спросить: а вы вообще пробовали этот Reiser4? время монтирования/отмонтирования просто чудовищно велико, скорость работы с ФС со временем очень быстро падает, плюс к тому же - не может восстановить половину открытых файлов при внезапном отключении питания

такая ФС в ядре нахер не нужна

при этом, Reiserfs очень быстрая и стабильная, для корня - идеальна

> И если уж на то пошло, что самое важное для файловой системы в 2010 году?

А это смотря для кого. :) При этом те, для кого самым важным является способность упаковать как можно больше двухкилобайтных файлов в мульти-терабайтный volume, вызывают у меня некое недоумение, мягко говоря.

Старпом просил передать, что в 2010 году ZFS уже как минимум 4 года как широко доступна и используется в продуктиве, тогда как btrfs еще даже из пеленок не вылезла.

Дыг и что? Вот кстати маленькое предсказание от одного из девелоперов ZFS, сделанное в июле 2009:

«Btrfs will be the default file system on Linux within two years. Btrfs as a project won't (and can't, at this point) be canceled by Oracle. If all the intellectual property issues are worked out (a big if), ZFS will be ported to Linux, but it will have less than a few percent of the installed base of btrfs.» http://lwn.net/Articles/342892/

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

Иногда (и/или для кого-то) выигрыш чуть больше погрешности измерений по одному показателю вполне стоит проигрыша по другому на порядок.

> Я этого не берусь отрицать, по меньшей мере в отношении половины из имеющегося количества в 64 или сколько там. Однако нужность не делает их менее барахлянскими с _моей_ точки зрения.

это слив

>>При заполнении пустого 659-мегабайтного раздела Btrfs файлами размером в 2 килобайта

у кого-нибудь наберется файлов такого размера на пару мегабайт?!

в кэш браузера загляни...
или, скажем, в /tmp при порядочном uptime

> Старпом просил передать, что в 2010 году ZFS уже как минимум 4 года как широко доступна и используется в продуктиве

И, да, вот например до сих пор не пофиксенный ZFS'ный багрепорт, открытый в 2003 году. И будет ли он вообще пофиксен – большой вопрос. http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

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

есть страшнее пример:

# du -h -s /var/spool/mail/vhosts
41G /var/spool/mail/vhosts

во-первых это NAS, основные разделы на нем под ext3
во-вторых, btrfs стоит с компрессией, и только ради компрессии,
т.к. данные которые я скидываю на этот раздел сжимаемы ( на данный момент там лежат снашпоты git/svn/итд , ну и всякое другое )

чем не устраивает ext4 - нет компрессии
чем не устраивает reiser4 - не включен в ядро, предыдущий не очень удачный опыт, вероятно из за несоответствия патча очередному минорному обновлению ядра, просто глюки