> Затем, что экстент позволяет помечать одним махом БОЛЬШОЙ регион. Это снижает оверхед по метаданным в ряде нагрузок. И в большинстве нагрузок это работает лучше. Поэтому большинство новых дизайнов взяли на вооружение эту технику. Правда просто? :)

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

> Затем, что экстент позволяет помечать одним махом БОЛЬШОЙ регион. Это снижает оверхед по метаданным в ряде нагрузок. И в большинстве нагрузок это работает лучше. Поэтому большинство новых дизайнов взяли на вооружение эту технику. Правда просто? :)

Большой это сколько? в zfs размер блока может быть несколько мегабайтов. в ext4 extent примерно того же размера (просто организация fs такая что не выделишь неделимый кусок больше чем группа позволит).
Поймите же наконец - extent не панацея - ту же функциональность можно реализовать другими средствами.
что в zfs и сделали. Зато COW в случае блочной организации делается проще. Правда просто?

> А приколись, "в среднем по больнице" экстенты будут при прочих равных в одной и той же конфиге эффективнее подобных недомерков под большинством нагрузок. Хуже от них как правило не становится, за исключением всяких клинических случаев "Шишкин-стайл" (когда некто поставил себе задачу нагнуть механику конкретной ФС).

Перестань курить траву и начинай думать. От того что переменный размер блока назвали extent - разницы не получается. Поверь у меня данных о том как ведут себя разные FS под большой нагрузкой - на порядок больше.
Большой - это реально большой - а не домашний NAS.
Не веришь - спроси Шигорина :) он таки догадывается из какой я конторы и чем занимаюсь.

> но бонусы архитектуры перекрывают минусы.
> И какие там "бонусы архитектуры"

Возможность без проблем выделить zvol в отдельный модуль и не иметь всякого POSIX overhead поверх тривиального контейнера с транзакциями. Хотя бы этот.
Ленивые транзации - сильно ленивые - что позволяют сильно агрегировать блоки в случае поточной записи. cache - что позволяет обходиться без подпорок типа flashcache/bcache и тому подобных, перемещая нужные данные на ssd для быстрого доступа.
raid-z сильно интересен, ибо близок к parity declustered raid, а не подпорки типа raid5/6.
чем это лучше - почитай в интернетах.

Мало?

> Чуть хуже ext4 + raid6,
> А чуть - это сколько в граммах?

около 10% если я правильно помню документ. А за ним лесть лениво.

> Да без понятия - вы даже конфиг не указали, не говоря о том что шансы что у меня "совершенно случайно" окажется "рояль в кустах" в виде точно такого же конфига - достаточно скромные. Тем не менее, помнится btrfs вставлял ZFSу в бенчах даже когда был молодой и зеленый. А с тех пор его оптимизили к тому же. И еще вагон места для оптимизаций остался.

Дисковая полка от CS9000. 5U84 в 2х raid-z. SAS, PCIe v3, LSI чип. Винты какие-то WD.
тюнинг не помню. Да и не я делал. Я лишь видел документы.