>> А ещё и екстентов есть родимое пятно в виде фрагметации.
> Это с фига ли? Научно обосновать сможете, или так, набросили вслепую, "пальцем
> в небо"? :) Могу даже забавный контрпример привести. Есть такая ФС
> - XFS называется. Отличается тем что трудно поддается фрагментации как раз.

Угу. И online дефрагментер там от хорошей жизни.

> Большая часть иных ФС фрагментируется сильно проще. Включая и ФС с
> блочной аллокацией вместо экстентов. Да, как ни странно XFS использует экстенты.
> С теоретической точки зрения: все что представимо блоками, представимо и экстентами.
> Поскольку они по большому счету всего лишь блоки переменного размера с
> очень большим диапазоном размеров. В типичной ситуации - ФС может положить
> несколько блоков последовательно. ФС с блочной аллокацией описывают размещение каждого
> блока вообще. ФС с экстентами описывают вместо этого диапазоны блоков. Что
> в общем случае более разумно. В итоге запись одного и того ...

От размеров томов блочным аллокаторам не холодно, ни жарко. От размеров файлов разве что, но учитывая, что блочный аллокатор - это такой сильно разветвлённый radix tree, метаданные растут очень и очень медленно.

> же по смыслу в типовой ситуации получается компактнее и меньше проблем
> с масштабированием при увеличении размеров томов.

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

>> Если уж меряться пиписьками, то уж в в чём-то посовременней.
> Не, извините. У блочных аллокаторов есть одна принципиальная проблема - они не
> очень хорошо масштабируются и имеют свойство тормозить на больших томах (педалить
> гигантские битмапы аллокации блоков и т.п. - нифига не быстро).

C чего бы? Cylinder groups никто не отменял, равно как и AG в XFS.

Поэтому
> практически все современные дизайны ФС почему-то все как одна используют экстенты.
> А на примере EXT2/3 и перехода с оных на EXT4 видно
> насколько выигрыш за счет экстентов бывает. В типичной ситуации экстенты рулят
> с жутким отрывом :). Ессно можно подобрать нагрузку на которой ФС
> с экстентами сольется. Однако ж почему-то при большинстве типовых нагрузок экстентные
> ФС нещадно надирают зад блочным. Что и способствует повсеместному внедрежу экстентов,
> собственно.

Собственно, ^^^^^. Вопрос типовых нагрузок обсуждайте со сферическими коневодами.

>> Современным SSD seektimes давно неинтересны, соответственно и экстенты как бы запоздали.
> А у блочных аллокаторов есть еще одна мерзенькая проблема. Они хранят описание
> аллокации для каждого блока. Что обеспечивает им плохую масштабируемость. Педалить большие
> битовые карты блоков или что-то подобное - не прикольно ни разу.
> И читать/писать многовато, и просто процом молотить при случае придется изрядно.
> Экстенты в общем случае могут представить сразу группу блоков одной компактной
> структурой. На чем и имеют свой профит - чем меньше метаданных
> юзается, тем быстрее работа с ними, очевидно :)

Очевидно и другое. Для блочного аллосатора процесс поиска в блоке сводится к прямому доступу к нужному элементу, в списке эктентов надо искать, с плачевными результатами для кэща. Всё не так очевидно, как вам кажется.

>> Можно бы привести Btrfs и ZFS и Hammer как список файловых систем хоть
>> каким-то боком замеченных в  инновациях, да NetApp c WAFL дубиной
>> стоит за спиной и особенно распинаться не велит :)
> Что-то не догоняю. У NetApp есть патент на идею CoW? Или экстенты?

CoW. И NetApp даже относится к нему серьёзно.

> Или b-деревья? Или где они дубиной махать смогут? А то тот
> же CoW используется в куче мест. Практически любая хрень со снапшотами,
> будь то ФС, диск виртуалки или что там еще - так
> или иначе разновидность copy-on-write. Техника CoW вообще весьма широко используется в
> программировании. Нельзя ли уточнить - какие именно у NetApp дубинки? Нормального
> описания что такое WAFL я толком не нашел. А уж описания
> какие у нетаппа патенты и подавно.

Ну, это не отмазка:

http://patft.uspto.gov/netacgi/nph-Parser?u=%2Fnetahtml...

один из.