> А теперь сравните с переменным размером блока. Блок может быть как 512
> байт, а следующий блок может быть 2 мегабайта - А в EXT4 например экстент может быть 128Мб за 1 присест. Некая разница с 2Мб, да?
> что позволяет одном логическим блоком накрыть произвольный регион в файле.
Не "произвольный" а "до 2 мегабайтов". Спору нет, это лучше чем пипеткой по 512 байтов и даже 4Кб. Но смотрится полумерами на фоне нормальных экстентов.
> И чем это отличается от extent? ведь правда просто.
Размером. Ну и количеством операций с метаданными в результате. Потому и будет сдристывать в бенчмарках и дальше.
> Большой это сколько?
У EXT4 например до 128Мб. В btrfs честно говоря с ходу не помню какие лимиты, но весь пойнт экстентов - в том чтобы за 1 присест метить *большие* регионы. Чем больше - тем лучше. В плане оверхеда по метаданным. Потому что хранить размер экстента где-то и как-то все это адресовать - придется, а если экстентов много и мелких - это будет не сильно лучше более дубовых техник. А в клиническом случае (много мелких экстентов) - может оказаться даже хуже. Т.к. оверхед на работу с метаданными будет конский.
Эталонный пример покладания экстентной механики - скачать мелкоблочный и многогигабайтный торрент без преаллокации. Получится туева хуча экстентов и вы узнаете как выглядит оверхед при работе с метаданными.
> в ext4 extent примерно того же размера
Да, всего 128Мб. Вместо 2. В какие-то 64 раза отличие. Всего-то :).
> (просто организация fs такая что не выделишь неделимый кусок больше
> чем группа позволит).
Ну да. Поэтому есть лимиты. Но 128Мб - это все-таки не 2. Это уже приличный кусок. В то что почти все записи умещаются в 128Мб - я еще поверю. В то что все записи лезут в 2Мб - да ЩАЗЗЗ.
> Поймите же наконец - extent не панацея - ту же функциональность можно
> реализовать другими средствами.
Экстенты не панацея а средство снижения оверхеда по метаданным при файловых операциях и ускорения этих операций. И нет, блок в 2Мб не аналог экстента в 128Мб а дешевый китайский пластиковый эрзац в лучшем случае. Потому что в 64 раза меньше. Значит на одну запись 128Мб оно дернется 64 раза. А ext4 - один раз. "Небольшая" такая разница по оверхеду.
> что в zfs и сделали.
Там сделали как обычно в духе саней: оверинженеринг с хреновыми параметрами на выходе и громким маркетинговым булшитом вытягивающим инженерные ляпы.
> Зато COW в случае блочной организации делается проще.
Не очень понятно чем стало так уж сильно проще. Блоки переменного размера как верно замечено не очень отличаются от экстентов в плане того что кластерфак с вычислением размещения и хранением подобных сведений - уже появляется. И величина вида "100 блоков" уже не является чем-то определенным, так что многие возможные упрощения вычислений отваливаются. А вот эффективность характерная для экстентов - она где?! Сделать в 64 раза больше операций чем EXT4 на записи 128Мб куска - это не "эффективность". Это фэйл. У экстентных дизайнов сроду нет таких мизерных лимитов на размер.
> Правда просто?
Да, у саней так вообще любят - забить на сложные проблемы, получить нечто заурядное, а потом силами маркетоидов вытягивать это инженерное решение, выпячивая сильные стороны и запинав под ковер недостатки. Которые, однако, никуда не деваются. Просто потом будут неприятные сюрпризы о которых маркетоиды рассказать забудут. А я не люблю неприятные сюрпризы и предпочитаю честное понимание свойств. Какой мне смысл самого себя обманывать? Ну маркетологам то понятно какой - они продажи соляры толкали. А вот идея надувать самого себя мне кажется довольно спорной.
>> А приколись, "в среднем по больнице" экстенты будут при прочих равных в одной и той же конфиге эффективнее подобных недомерков под большинством нагрузок. Хуже от них как правило не становится, за исключением всяких клинических случаев "Шишкин-стайл" (когда некто поставил себе задачу нагнуть механику конкретной ФС).
> Перестань курить траву и начинай думать. От того что переменный размер блока
> назвали extent - разницы не получается.
А разница в максимальном размере. Два мега - жалкая пародия на экстенты. В плане overhead по метаданным и числу операций.
> том как ведут себя разные FS под большой нагрузкой - на
> порядок больше.
Никак не отменяет здравый смысл. И результаты бенчей с ним почему-то согласуются.
> Большой - это реально большой - а не домашний NAS.
А большая нагрузка - это работа со скоростями близкими к скорости линейного доступа накопителя. Если в терминах ФС. Работа с 100500 дисков в рамках одной ФС - это вообще отдельный случай, у вас оно кажется уже начинает становиться из разряда клиники. Если у вас задача вида "160Tb одним куском" - есть нехилый шанс что гнать надо архитекта такой системы, ссаными тряпками и сpaной метлой. А не геройствовать, фикся bottleneck-и в 1 системе, по принципу "ничего не знаю, после оптимизации даже кит и слон у нас полетят". Кэп намекает что 10 серверов с 16Тб дисков каждый имеют все основания работать лучше чем 1 сервак с 160Гб переросточным диском. Меньше мест для bottleneck-ов.
> Не веришь - спроси Шигорина :) он таки догадывается из какой я
> конторы и чем занимаюсь.
По моим наблюдениям ты занимаешься болтологией, поливанием линя помоями и выгораживанием задницы саней и их технологий. При том я упорно не вижу ничего такого замечательного в этих сановских технологиях. В лучшем случае нечто достаточно заурядное и средненькое оказывается. А маркетинговых соплей зато - как для панацеи прямо.
> Возможность без проблем выделить zvol в отдельный модуль и не иметь всякого
> POSIX overhead поверх тривиального контейнера с транзакциями.
Это очень нишевой "плюс архитектуры", нужный немногим. Обычно всем нужна прежде всего файловая система все-таки. И вот как файловая система ZFS выглядит переростком с довольно заурядными параметрами и рядом бестолковых ляпов.
> Хотя бы этот.
Не вижу чего ради оно должно считаться жирным плюсом "само по себе". Не, ну я понимаю что соляра - как вигвам, ничего нет. Поэтому в ZFS сани впихнули вообще все чего не хватало в соляре. Но в других осях и до ZFS уже был и менеджмент томов и управление кэшом. И поэтому за плюс впихон всего этого в ФС может считаться только с большими оговорками. Лишь когда дает что-то особенное, чего иначе не получается или получается плохо. В btrfs например RAID как минимум чисто техничечки может то, чего не может RAID блочного уровня: рулить уровнями RAID пообъектно. Ну ок, это мне понятно - достаточно интересный маневр, основанный на том факте что ФС сама рулит томами, знает на каких девайсах и сколько места и решает куда и сколько раскидать. И в нужный момент может принять решение "а как раскидывать по девайсам, собственно". Раскидав так как попросил юзер, если конечно это технически возможно (aka достаточно места на разных девайсах для реализации запрошенного варианта хранения). В этом случае мне такая архитектура еще понятна. А "сферический ZVOL в вакууме" конечно замечательно, но чего такого уникального и кому оно дает? Или может быть от того факта что "это ZVOL" что-то станет работать в 2 раза лучше чем было?
> Ленивые транзации - сильно ленивые - что позволяют сильно агрегировать блоки в
> случае поточной записи.
С хрена ли оно плюс, если так или иначе объединять блоки умеют все современные ФС?
> cache - что позволяет обходиться без подпорок типа flashcache/bcache и тому подобных,
Опять же - см. выше. Подпорки или не подпорки - вопрос эстетики и на результат в конечном итоге влияет слабо. Что нового эта технология привносит? Или что начинает работать лучше чем было? Иначе какой же это козырь относительно других?
> перемещая нужные данные на ssd для быстрого доступа.
Спору нет - фича полезная. Но опять же - такое и btrfs чисто технически может.
> raid-z сильно интересен, ибо близок к parity declustered raid, а не подпорки
> типа raid5/6.
Ок, сам по себе raid-z не самая плохая штука. Как RAID. Как считается parity в RAID5/6 мне не особо нравится, недостаточно generic схемы. Тем не менее, в RAIDовых вопросах btrfs интересен тем, что технически он может рулить уровнем RAID-а пообъектно. Так что ценные файлы можно хранить с бОльшим расходом места, а барахло можно например по скорости оптимизировать, а если продолбается - "еще раз закачают, не развалятся". Ну там отчеты бухов - они более важны чем видео с корпоративного бухалова. Ну или мои программы мне нужнее чем допустим мувик с торентов. Ибо переписывать пол-проги при крахе обидно, а мувик с торента я еще раз перекачаю, если оно того вообще стоит.
> Мало?
Да вроде не дофига.
> около 10% если я правильно помню документ. А за ним лесть лениво.
Сдается мне что этот процент весьма варьируется в зависимости от ворклоада, конфиги и прочая. И далеко не всегда 10%. Кстати насколько всем надо 169Тб тома - видно хотя-бы потому что поддержку всего этого в EXT4 и тулсы запилили относительно недавно, хотя дисковый формат как бы не возражал против этого достаточно давно.
> Дисковая полка от CS9000. 5U84 в 2х raid-z. SAS, PCIe v3, LSI
> чип. Винты какие-то WD тюнинг не помню. Да и не я делал. Я лишь видел документы.
Там еще поди роялит CPU, память и прочее. А в чем пойнт спрашивать "сколько на этом выжмет ZFS"? Думаешь, я побегу собирать такую конфигу и измерять? Специально для тебя?
