> Итак: раздел размером 1031903 секторов. Сначала попробовал с 2048-байтными файлами, получилось 215250 файла, 0.83438075 от размера раздела. Дальше zfs отжог:

$ rm /test/1

rm: /test/1 not removed: No space left on device

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

Пришлось переформатировать.

Ну это ты поспешил. Можно просто некоторому количеству файлов сделать truncate.

Итого результаты на данный момент:

2048 байт 215250 файлов 0.83438075

2049 байт 175740 файлов 0.68155944

4097 байт 101068 файлов 0.7837378

Ну и? Чего сказать-то хотел?

Результаты предсказуемые. Для хранения файла на 2049 байт требуется пять секторов, то есть для хранения данных 175740 файлов по 2049 байт нужно 878700 секторов. Для хранения 215250 файлов размером 2048 байт потребуется 4 сектора на файл или 861000 секторов. Для хранения 101068 файлов по 4097 байт потребуется по 9 секторов на файл или 909612 секторов. Меньше количество файлов - меньше места занимают метеданные.

Да, печально.

Решил проверить сам. Создал на новом еще не форматированном терабайтном диске раздел btrfs на весь диск. На нем создал 1 миллион файлов по 2048 байт из urandom. Вместо ожидаемых ~2Gb на диске занято 8.7Gb, то есть лишь 23% потраченного места ушло на сами данные, и 77% занято метаданными. При этом, судя по-всему, размер ФС почти не влияет на относительный объем метаданных.

> И да, обрати внимание, что Шишкин работает в RedHat, т.е надо ждать рейзер4 в ядре, и возможно даже в качестве умолчальной ФС ;-)

Мечты-мечты... Совсем не факт, что он там работает над Reiser4. Скорее уж над btrfs, иначе с какого перепугу бы ему в ней ковыряться, тестировать и проверки кода делать? Нецелевые траты времени получаются. Ну а занести Reiser4 в ядро на скандалах с btrfs вряд ли получится.

>не факт, что он там работает над Reiser4. Скорее уж над btrfs

Прозреваю саботаж!

Для больших файлов есть XFS, которая, кстати, меньше плодит метаданные.

А можно еще сделать так, чтобы она не портила файлы, открытые на запись при холодном ребуте?

Разориться на бесперебойник?

>>А можно еще сделать так, чтобы она не портила файлы, открытые на запись при холодном ребуте?

Разориться на бесперебойник?

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

>>Рейзер4 имеет наращиваемую архитектуру, т.е в теории из неё наверно возможно и что нибудь типа zfs соорудить. Я например не слышал о ФС с наращиваемой архитектурой.

Я ржал минут пять. Ну ты отжёг. Ты хоть вики по бтрФС читал? Знаешь её основную направленность?

А что ты читал про рейзер4 в свободное от ржания время ?

>Разориться на бесперебойник?

У меня уже есть APC Smart-UPS 750. Но проблем XFS это никак не решает.

тема была про btrFS. Не надо от неё отходить, а тем более постить комментарии предварительно не изучив про что пишешь.

>тема была про btrFS. Не надо от неё отходить, а тем более постить комментарии предварительно не изучив про что пишешь.

Единственная вещь к которой на ЛОР-е относятся серьёзно, это троллинг в разных формах, стремясь к гармонии ;-)

Здесь тебе надо напрячь серое вещество и понять что такое гармоничный троль и чем он отличается от тонкого троля, так как мне неохота давать определение.

И таки да, тебе надо поменять парсер - твой текущий не осилил, что когда говорят, что рейзер4 можно нарастить до бтрфс, то это говорят в том числе и про бтрфс.

>Единственная вещь к которой на ЛОР-е относятся серьёзно, это троллинг в разных формах, стремясь к гармонии ;-)


Ну хватит уже говорить за всех.
А парсер у меня на dancing trees. И да, всё таки советую почитать вики про назначение и фичи btrFS прежде чем сравнивать с всякими юморескамиFS.

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

Обидно дяде, что его тормозной райзер закопать собрались? Сочувствую. А он не хочет обсудить, почему большие разделы с райзером монтируются так долго, что когда у меня была мандрива, то она выключала при этом процессе сплэш, выкидывая меня в консоль. Типа, «хозяин, оно зависло».

> У меня нет желания сейчас расписывать мою точку зрения. Писать подробно слишком долго, в том числе и потому что для разных целей сравнительная важность фич разная. А писать коротко – не имеет смысла.

Так и запишем - собственной точки зрения нет.

Но пока что это голословное утверждение от непонятного анонимуса.

Следите лучше за тем, чтобы ваши собственные утверждения были неголословными

Может быть вы будете так добры, и укажете, в чем конкретно она ошибается (и вводит в заблуждение [...])?

Может вам еще все разжевать и в рот положить?

Хотите примеров? Вот они:

[quote] The central on-disk data structure was the slab - a chunk of disk divided up into the same size blocks, like that in the SLAB kernel memory allocator, which he also created. [/quote] [quote] In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS. One of the major problems with the ZFS approach - «slabs» of blocks of a particular size - is fragmentation. Each object can contain blocks of only one size, and each slab can only contain blocks of one size. You can easily end up with, for example, a file of 64K blocks that needs to grow one more block, but no 64K blocks are available, even if the file system is full off nearly empty slabs of 512 byte blocks, 4K blocks, 128K blocks, etc. [/quote]

Желаю вам успехов в поисках того, о чем она пишет, в сегодняшнем коде ZFS.

я готов довольствоваться некорректным поведением в некоторых случаях (и при выолнении некоторых условиях) если этой ценой я могу получить преимущество в чем-то другом.

Желаю вам успехов в вашей профессиональной деятельности..

Так что, опять, one size doesn't fit all.

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

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

То есть вы, на самом деле, нифига не знаете и у меня же и спрашиваете? Тюю, а «так дысал, так дысал»..

Впрочем, я признаю, что об архитектуре ZFS я знаю только со слов Авроры/Хенсон, и если вдруг окажется, что ZFS повсюду использует бэкреференсы и не использует слэбов, то тогда я был неправ, да.

То есть вы ничего не знаете не только о btrfs, но и о ZFS, и тем не менее позволяете себе заявления вселенского мастшаба.. Ну-ну.

И, да, я видел состояние. Конкретно, я видел, что по прошествии 7 лет (из которых, сколько, 3 года уже? система считается стабильной) состояние не fixed.

Состояние «fix understood». Так что дойдут руки - фикснут. Есть такая штука - приоритеты, и вряд ли мнение аналитегов с лора имеет на них какое-либо влияние.

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

Я скорее удивлюсь, если по прошествии года он все еще не будет удаляться нормально. Будет удаляться - я порадуюсь. Вот только когда это будет работать - тогда и призодите заявлять что фича есть. Иначе какой от нее толк, если чтобы ею воспользоваться, нужно вычистить файловую систему.

>Кстати, прошу простить меня за грубость в первом сообщении, я почему то думал что пишу из-под анонимуса.

Ты не переходил границ допустимого, и кстати ты единственный отреагировал на моё провокационное предложение нарастить рейзер4 до бтрфс

внезапно - даже из под анонимуса только в очень редких случаях надо грубить

;-)

> Размер свободного пространства почти константа. И если несколько сохранённых на btrfs html страниц с картинками отожрут половину оставшегося места, то в топку такие ФС - ext3-4 наше всё.

Если место так важно, то выбирать надо совсем не ext3-4.

# dd if=/dev/zero of=reiserfs bs=1000000 count=700
# mkreiserfs -f reiserfs
# mount reiserfs /mnt/test -o loop,rw
# i=1
# time while dd if=/dev/zero of=/mnt/test/file_$i bs=2048 count=1 2>&1; do i=$((i+1)); done | tail -4
dd: запись `/mnt/test/file_300966': На устройстве кончилось место
1+0 записей считано
0+0 записей написано
 скопировано 0 байт (0 B), 0,0846309 c, 0,0 kB/c

real    5m31.957s
user    1m46.964s
sys     3m56.415s

ext4 горько плачет в углу.

B-trees

This is easily shown by modelling variable-length records

а кто и как будет иметь дело с жтими «index»? хранить, разбирать и т.д.?
я же говорю - хотите узнать чем это пахнет - почитайте про MUMPS и её подходы к хранению и обработке.
Проблема будет в индексах физических ограничениях на число байт в секторах.