Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен.

Это слишком ресурсоёмко, нафиг надо.

Голословное заявление.

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

Это костыль. Анонимус выше более подробно разъяснил, что от размера раздела проблема не зависит. Дерево, которое используется в btrfs, не пригодно для хранения айтемов переменного размера. Поэтому любое количество костылей вроде «а ограничим-ка мы максимальный размер айтема» не способно полностью исключить описанный Шишкиным вариант дегенерации файловой системы.

Или алгоритм сжатия поменяй на менее ресурсоемкий. А то некоторые включат gzip-9 и ожидают, что все будет так же быстро и жрать столько же CPU, как и с lzjb.

Дерево, которое используется в btrfs, не пригодно для хранения айтемов переменного размера.

Как эту проблему решили в zfs? Блоки переменного размера?

Судя по вики, в zfs эту проблему «решили» неиспользованием B-деревьев (равно как и остальных деревьев: там хэш-таблицы).

Вот оно как, я ошибочно полагал, что во всех COW FS один и тот же матан.

Судя по вики, в zfs эту проблему «решили» неиспользованием B-деревьев (равно как и остальных деревьев: там хэш-таблицы).

А поподробнее - где именно там хэш-таблицы?

Они используются для хранения содержимого директорий.

если что, процитированное тобой было в защиту ZFS, но это, безусловно, неважно, тебе же лишь бы поспорить.

Как эту проблему решили в zfs? Блоки переменного размера?

Там обычное дерево блоков фиксированного размера с блоками косвенной адресации. Пока дерево состоит из одного блока - размер его может меняться, как только блоков становится больше, чем один - размер блока фиксируется. Это позволяет хранить файлы, которые по размеру меньше recordsize в виде одного блока подходящего размера.

Проскакивала новсть, что btrfs с нестабильной функциональностью уже стабильна. Я в этом не уверен.

Resolved Fixed :)

Они используются для хранения содержимого директорий.

Без этого уточнения твое изначальное утверждение некорректно.

если что, процитированное тобой было в защиту ZFS, но это, безусловно, неважно, тебе же лишь бы поспорить.

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

шататная функция

А получилось тонко :)

Ок, спасибо за уточнение. (Я там отметил, что сужу исключительно по вики.)

Кстати, а где там используются деревья?

с одной стороны соглашаешся, что дизайн zfs хорош

это ты сам выдумал, я такого не говорил

с другой стороны утверждаешь, что шататная функция rollback сделана для идиотов

не для идиотов, а по-идиотски

Это позволяет хранить файлы, которые по размеру меньше recordsize в виде одного блока подходящего размера.

Хорошее решение. iZEN залогинься наконец )

Это костыль

Это детский лепет. Костылём при желании можно назвать что угодно.

от размера раздела проблема не зависит

Никакой проблемы нет. Есть непонимание, продиктованное желанием, чтобы в Btrfs было «всё как у людей».

Дерево, которое используется в btrfs, не пригодно для хранения айтемов переменного размера

Даже если так - можно задать ограничение.

Поэтому любое количество костылей вроде «а ограничим-ка мы максимальный размер айтема» не способно полностью исключить описанный Шишкиным вариант дегенерации файловой системы.

Опять бестолковое блаблабла без пруфов. Короче, идите гуляйте на пару с Шишкиным и вашим детским лепетом. Я уже показал, что Btrfs что с max_inline, что без него ведёт себя совершенно предсказуемо.

Ща я запилю наглядное сравнение. Промежуточный вердикт таков: 16-MiB раздел на btrfs способен вместить в себя 20336 пустых файлов, а аналогичного размера раздел на reiser4 — 100263 пустых файла.

И вот только не надо тут кричать, что, мол, синтетический тест: это наглядная демонстрация длины МПХэффективности хранения метаданных :)

Запили ещё сравнение на разделе в пару Гиб и файлах в 0.5-2 Киб.

Для понимания масштабов бедствия.

Через некоторое время. Тут один забавный баг в r4 отловился — надо посмотреть, это следствие моих допиливаний или нет.

На мой взгляд, всё норм.

Вот только очевидно, что 1000000 файлов по 2048 байт на двухгиговый раздел с btrfs не влезет, ибо ты создал около 720 тысяч файлов и уже начал испытывать проблемы со свободным местом, ибо его стало мало и оно стало очень фрагментированным (поэтому то твой старичок начал тарахтеть). Для еще 280 тысяч файлов тебе потребовалось бы еще около 550M только для данных, что уже превосходит размеры раздела, и это мы еще не учли метаданные для недостающих файлов.

А так все норм :)

ты обдолбался. размеры блоков фс сравни для начала

Неет, в том-то и дело. Каждая из этих ФС предположительно умеет tail packing. Вот мы и проверяем, насколько хорошо они это умеют.

Неет, в том-то и дело. Каждая из этих ФС предположительно умеет tail packing. Вот мы и проверяем, насколько хорошо они это умеют.

Какой tail packing если ты ведешь речь о пустых файлах?

Как будто в случае пустого файла нечего паковать в дерево (или не паковать, если ФС тупая).

Как будто в случае пустого файла нечего паковать в дерево (или не паковать, если ФС тупая).

Паковать-то может и есть что, только какое это отношение имеет к хвосту, которого нет?

Ок, я не совсем корректно выразился. Мы рассматриваем ФС, которые хранят метаданные (включая хвосты) в дереве, и пытаемся выяснить, какая из ФС делает это эффективнее.

Сделал похожий эксперимент на ZFS, только включил сжатие:

<code> # mkfile -n 2g /var/tmp/pool # # zpool create -O atime=off -O compress=lzjb pool /var/tmp/pool # # for i in $(seq 1000000); do dd if=/dev/zero of=/pool/file_$i bs=2048 count=1 &>/dev/null; done # # zpool list pool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool 1.98G 183M 1.81G 8% 1.00x ONLINE - # zfs list pool NAME USED AVAIL REFER MOUNTPOINT pool 182M 1.77G 181M /pool # # zpool scrub pool # # mdb -k

ffffc10012e5c000::spa -v

ADDR STATE NAME ffffc10012e5c000 ACTIVE pool ADDR STATE AUX DESCRIPTION ffffc10012bd0800 HEALTHY NONE root ffffc10012b64800 HEALTHY NONE /var/tmp/pool

ffffc10012e5c000::zfs_blkstats

Dittoed blocks on same vdev: 39963

Blocks LSIZE PSIZE ASIZE avg comp %Total Type 1 512 512 1.50K 1.50K 1.00 0.00 object directory 1 512 512 1.50K 1.50K 1.00 0.00 object array 1 16K 1.50K 4.50K 4.50K 10.66 0.00 packed nvlist 151 856K 365K 1.06M 7.25K 2.34 0.58 SPA space map 30.7K 493M 47.2M 94.6M 3.07K 10.41 51.86 DMU dnode 2 4K 1K 2K 1K 4.00 0.00 DMU objset 1 512 512 1.50K 1.50K 1.00 0.00 DSL directory child map 2 1K 1K 3.00K 1.50K 1.00 0.00 DSL dataset snap map 4 2K 2K 6.00K 1.50K 1.00 0.00 DSL props 8.07K 129M 43.3M 86.6M 10.7K 2.97 47.52 ZFS directory 1 1K 512 1K 1K 2.00 0.00 ZFS master node 1 512 512 1K 1K 1.00 0.00 ZFS delete queue 1 128K 5.00K 15.0K 15.0K 25.60 0.00 SPA history 1 512 512 1.50K 1.50K 1.00 0.00 DSL dataset next clones 4 2K 2K 4K 1K 1.00 0.00 ZFS user/group used 1 512 512 1K 1K 1.00 0.00 SA master node 1 1.50K 512 1K 1K 3.00 0.00 SA attr registration 2 32K 3.50K 7.00K 3.50K 9.14 0.00 SA attr layouts 3 1.50K 1.50K 4.50K 1.50K 1.00 0.00 DSL deadlist map 1 512 512 1.50K 1.50K 1.00 0.00 DSL dir clones 39.0K 623M 91.0M 182M 4.67K 6.84 100.0 Total

</code>

Сделал похожий эксперимент на ZFS, только включил сжатие:

# mkfile -n 2g /var/tmp/pool
#
# zpool create -O atime=off -O compress=lzjb pool /var/tmp/pool
#
# for i in $(seq 1000000); do dd if=/dev/zero of=/pool/file_$i bs=2048 count=1 &>/dev/null; done
#
# zpool list pool
NAME   SIZE  ALLOC   FREE  CAP  DEDUP  HEALTH  ALTROOT
pool  1.98G   183M  1.81G   8%  1.00x  ONLINE  -
# zfs list pool
NAME  USED  AVAIL  REFER  MOUNTPOINT
pool  182M  1.77G   181M  /pool
#
# zpool scrub pool
#
# mdb -k
> ffffc10012e5c000::spa -v
ADDR                 STATE NAME
ffffc10012e5c000    ACTIVE pool
    ADDR             STATE     AUX          DESCRIPTION
    ffffc10012bd0800 HEALTHY   NONE         root
    ffffc10012b64800 HEALTHY   NONE           /var/tmp/pool
>
> ffffc10012e5c000::zfs_blkstats
Dittoed blocks on same vdev: 39963

Blocks  LSIZE   PSIZE   ASIZE     avg    comp   %Total  Type
     1    512     512   1.50K   1.50K    1.00     0.00  object directory
     1    512     512   1.50K   1.50K    1.00     0.00  object array
     1    16K   1.50K   4.50K   4.50K   10.66     0.00  packed nvlist
   151   856K    365K   1.06M   7.25K    2.34     0.58  SPA space map
 30.7K   493M   47.2M   94.6M   3.07K   10.41    51.86  DMU dnode
     2     4K      1K      2K      1K    4.00     0.00  DMU objset
     1    512     512   1.50K   1.50K    1.00     0.00  DSL directory child map
     2     1K      1K   3.00K   1.50K    1.00     0.00  DSL dataset snap map
     4     2K      2K   6.00K   1.50K    1.00     0.00  DSL props
 8.07K   129M   43.3M   86.6M   10.7K    2.97    47.52  ZFS directory
     1     1K     512      1K      1K    2.00     0.00  ZFS master node
     1    512     512      1K      1K    1.00     0.00  ZFS delete queue
     1   128K   5.00K   15.0K   15.0K   25.60     0.00  SPA history
     1    512     512   1.50K   1.50K    1.00     0.00  DSL dataset next clones
     4     2K      2K      4K      1K    1.00     0.00  ZFS user/group used
     1    512     512      1K      1K    1.00     0.00  SA master node
     1  1.50K     512      1K      1K    3.00     0.00  SA attr registration
     2    32K   3.50K   7.00K   3.50K    9.14     0.00  SA attr layouts
     3  1.50K   1.50K   4.50K   1.50K    1.00     0.00  DSL deadlist map
     1    512     512   1.50K   1.50K    1.00     0.00  DSL dir clones
 39.0K   623M   91.0M    182M   4.67K    6.84    100.0  Total
>

Что можно сказать:

• потребовалось 182M для метаданных о миллионе файлов вместе с метаданными каталога, в котором они находятся
• за счет компрессии ни одного блока для этих файлов не было выделено (нет строки ZFS file data)
• На метаданные каталога на диске ушло 86,6М
• На метаданные собственно файлов - 95,4 (182 - 86,6)
• Миллион файлов по 2К без сжатия тоже не влез бы на пул ZFS на двухгиговом устройстве :)

это наглядная демонстрация эффективности хранения метаданных

На милипистрических разделах, да.

Ну так я в тесте не включал сжатие.

Да, всё норм. Проблемы, которые становятся актуальными только в специально созданных феерических условиях - это не проблемы вовсе. Это всё равно, что затолкать человека в ящик 0,5х0,5х0,5 метра и удивляться, почему он превратился в не очень живую кашицу.

С этим вашим тредом мне какая-то убийственная херь под утро снилась: будто бы тотальный зомбоапокалипсис, я был укушен, и кто-то из здешних одминов в обмен на антидот предлагал угадать, какую ФС со снапшотами он использует на боевых серверах. Я сказал «NILFS4» (такая вообще существует?), а какая-то маленькая девочка покрутила у виска и сказала «Tux3». И выиграла. А я сдох.

Btrfs native RAID vs mdadm на RAID 0, 1, 10, 5 и 6

Результаты очень неоднозначные.

так райзер на разделе в 4 тб явно проиграет btrfs, потому он и приводит разделы, под которые создавалась эта фс.

Ну так я в тесте не включал сжатие.

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

так райзер на разделе в 4 тб явно проиграет btrfs, потому он и приводит разделы, под которые создавалась эта фс.

слова, слова...

У меня лишних четырёх терабайтов нет (и лишней недели, в течение которой эти четыре терабайта будут заполняться пустыми файлами, тоже нет). Разупорись.

В общем погонял я ещё немного эту бажную btrfs, которая вся стабильна. Баг с compress-force не только в ядре 3.17.1, но также прекрасно себя чувствует в ядре 3.16.0-24 (дефолтное ядро в убунте 14.10). Скорее всего для большинства это не так важно, как я понял всем пофиг, что многие данные btrfs даже не пытается сжать, но проблема в том, что это базовый функционал, который на поверхности, я даже представить боюсь что же там наколбашено внутри. Яркий, кстати, пример разработки софта по ущербной парадигме devops (а также agile и прочий шлак), получите распишитесь. Потыкаю ещё немного «это», потому как есть подозрения, что когда при серъёзной нагрузке эта штука делает sync она фризит систему, хотя система установлена на отдельном ssd.

в твоем сне батарею не встретил очередной раз?

12309 таки побеждён!

4.2, он проявляется порой

Ты в игнор хочешь, тупло?

Держи нас в курсе, хехе.

ок

наверное, мне от этого будет очень прискорбно!
О нет, только не игнор, умоляю!! :D

iZEN залогинься наконец )

ты кастани его и спроси, он ли это

В 3.17.2 исправлена регрессия из 3.17.1. В релиз Opensuse 13.2 вошло ядро 3.16.x

у меня без проблем было много файлов и данных на btrfs, снапшоты всё делались, она конечно не замена zfs, но под свои задачи она подходит хорошо.Представь сколько надо было бы оперативы под файлопомойку с ≈5 тб данных....

Да работает оно, вроде как, гоняю потихоньку суровыми стресс-тестами, живёт, если compress-force не включать. Просто я впервые в жизни решил эту btrfs попробовать и словил эпичный баг через 30 минут использования, обидно ))