> А в EXT4 например экстент может быть 128Мб за 1 присест. Некая разница с 2Мб, да?Хотите скажу страшную тайну - реальных таких размеров не бывает. Да и размер группы не позволит это сделать.
и mballoc не позволит выделить такой размер - ну не умеет он как не старайся. Не затачивали его под это.
Так что не надо рассказывать сказки. То что теоритически так можно сделать - то это не значит что так сработает.
> А большая нагрузка - это работа со скоростями близкими к скорости линейного доступа накопителя.
Большая нагрузка это когда SAS шина не успевает за дисковой полкой. а потом ложится PCI-e. А диски еще позволяют дальше качать.
> Кэп намекает что 10 серверов с 16Тб дисков каждый имеют все основания работать лучше чем 1 сервак с 160Гб переросточным диском. Меньше мест для bottleneck-ов.
Кэп намекает что 10 серверов с таким количеством дисков жрут сильно больше электричества требуют в 10 раз больше площащи под датацентр. Понимаешь в чем дело... у нас объемы измеряются Pb, а не Тb.. ну там хранилище на 10Pb, или 60Pb.. сколько серверов потребуются с 16T дисками? а сколько с 160T?
> Это очень нишевой "плюс архитектуры", нужный немногим. Обычно всем нужна прежде всего файловая система все-таки.
А нам не нужна - представляете? даже вредна. Отказ от posix уровня дает +30% производительности.
зачем это надо.. Да хотя бы для Swift хранилищь или чего другого object storage или для HPC.
> Не вижу чего ради оно должно считаться жирным плюсом "само по себе"
Остальной бред поскипан. Райд по объектам весьма частный случай parity declustering. Который опять же придуман был не сотрудниками btrfs.
> С хрена ли оно плюс, если так или иначе объединять блоки умеют все современные ФС?
Знаете ли есть разница объединить за 1с или за 200с. это разные интервалы. я не зря сказал очень ленивые.
> перемещая нужные данные на ssd для быстрого доступа.
> Спору нет - фича полезная. Но опять же - такое и btrfs чисто технически может.
Технически это может любая FS, а в рабочем состоянии есть только в zfs.
> Опять же - см. выше. Подпорки или не подпорки - вопрос эстетики и на результат в конечном итоге влияет слабо.
так вы определитесь - возможность встроить кэш в FS это полезная штука или на результат не влияет? а то вы уже запутались :)
Вот к примеру свеже убитый ext4 том - из-за raid mirror на котором лежал журнал этой FS. из-за того что ext4 зачем-то пихает в журнал все директории с которыми работает при lookup - даже при no_atime - получили кашу.
а всего-то raid начал синкать диски в момент journal replay. Итог убитый диск и 2 дня на написание инструментария по выколупывания данных.
> Кстати насколько всем надо 169Тб тома - видно хотя-бы потому что поддержку всего этого в EXT4 и тулсы запилили относительно недавно, хотя дисковый формат как бы не возражал против этого достаточно давно.
Поддержку 128Т запилили. причем около года назад - до этого e2fsck корежил файлы за пределами 32T. Режим over 128T пока не тестирован в e2fsprogs и ext4. честно. Причем я знаю до сих пор места в e2fsprogs которые могут выстрелить при работе с дисками в 128Т и данные будут частично поехерены.;
Так что на свой страх и риск..
