>> Вкатить 1 х 100Мб кусок в любом случае оптимальнее чем порядка 800 кусков для того же самого делать.
> Вкатить 1 х 100Мб кусок - Это сфероконь в вакууме. В реальности
> основные задачи, как раз наоборот, регулярно вкатывать куски по 100Кб.Как бы от задачи сильно зависит.
> Могу их Вам перечислить:
> - Перезаписать в произвольном месте файла кусок 8-16Кб (базы данных)
ZFS почему-то на этих задачах ничего такого интересного не демонстрирует.
> - Дописать в конец файла несколько десятков килобайт (логи)
Ну, допустим. Только интенсивность этих операций невысока и всем похрену на их скорость.
> - создать и удалить в некоем каталоге несколько десятков - сотен файлов
> средним размером около 100Кб (кеширование, например, почты, веба или чего-либо подобного)
Капитан намекает что файлы бывают разные, поэтому не вижу вреда от возможности выделить одним чихом и несколько мегов, в случае если файл окажется крупнее. Кстати если уж на то пошло, ZFS традиционно сливает тест postmark у похорониксов с разгромным счетом. Что-то не работает ваш юзкейс, а?
> Ряд можно продолжать. Приведите plz, пример полезной загрузки, когда нужно постоянно писать
> по 100Мб? Файлопомойка студенческой общаги?
Файлопомойки (не обязательно студенческие). Фото и видео хостинги, бэкапы, зеркала дистрибутивов и репов и куча всего еще. Вообще, от возможности выделить более крупный экстент хуже как-то не становится (а с чего?), а вот лучше - может. Поэтому не вижу смысла лимитировать размер экстента. От более крупных экстентов может стать лучше, если удалось сэкономить, но хуже то не станет.
> И да, посчитайте как в вышеупомянутых задачах будут вести себя 100Мб экстенты.
У, я думал что вы умнее, а вы оказывается ни в зуб ногой :(. Нормально они себя ведут, потому что это максимальный размер. Это не мешает делать экстенты меньше. Если надо меньше, будет меньше. Кстати можете посмотреть на постмарк у похороникса, вместе похохочем над "якобы оверхед" у EXT4 по сравнению с ZFS. Как раз примерно указанный вами сценарий - относительно мелкие файлы оптом. Лол :). Подозреваю что дело в том что соотношение "записать 1 экстент" или например "записать 3 экстента" при мелких файлах совсем невкусно: относительный процент на саму запись данных не так уж велик и поэтому эффективность работы с метаданными начинает сильно роялить. Ну вот видимо ZFS и тушуется.
> Напоминаю про COW, экстенты нельзя править, только записывать заново.
Не вижу принципиальных отличий. Я исходил из общей логики: лопатить структуры которые описывают экстент - придется. Вот оттуда и оверхед: чем больше одним куском описывает экстент, тем меньше относительный оверхед на работу с структурами ФС для записи одного и того же объема данных.
[...]
> коэффициент 10. получаем 160кб.
Тут проблема будет не столько в самих 160 Кб, сколько в том что часть этих данных надо вычислять и все это не обязательно удастся записать одним куском. Что и просадит скорость. Проще говоря, файловая система будет делать довольно много действий которых можно было бы избежать, что не добавит ей скорости работы. Кстати может поэтому постмарк и тухнет? Если на больших файлах все будет похоже на 0.1% указанный вами, то вот когда файл мелкий, запись 1 экстента или допустим 3х - разница в _три_ раза получается. Если время записи самих данных маленькое, это начнет сильно роялить.
> И вспоминаем, что только что мы записали на диск 100Мб. Оверхед - 0.1%
Как бы то что по объему 0.1% еще не означает что время генерации метаданных и их записи будет 0.1% от потраченного на операцию времени. Тут все очень зависит от. Если на больших файлах нечто похожее на это соотношение еще можно будет увидеть, то вот на файлах размерами порядка нескольких экстентов ZFS... не получится ли как в postmark похороникса? :)
> Осталось придумать, как этот оверхед измерить :-) А вот с blocksize 4/8кб от
> ext2-3, ufs и т.д. оверхед уже вполне заметный.
Естественно, им еще и битмапы занятости надо обновлять на каждый пшик. Что скорости им совсем не добавляет.
>> Я бы сказал что у них объем маркетинга зачастую перевешивал объем здравого смысла.
> Есть в этом правда. Но про эффективность я читал в блогах разработчиков.
У разработчиков есть такое свойство: они все очень любят себя хвалить.
> Они, в частности некоторые структуры, которые на диске хранятся в виде
> списков/таблиц, в памяти разворачивают в деревья,
Такой подход возможен даже для антикварного FAT, но проблема в том что это может жрать довольно много памяти и кроме того "на холодную" этих данных в памяти нет, при холодном доступе тратится некое время на построение в памяти нужных структур. И всегда держать таковые структуры в памяти, особенно если их много, можно только если памяти реально дохрена и она больше никем не используется, а это верно разве что для выделенных файлсерверов. Такой подход - индикация того что дисковые структуры надизайнили не так как надо было бы, а потом передумали и воткнули компромиссный костылик.
> тем самым сильно ускоряя обработку метаданных, но, при этом, теряют
> возможность оперативно подгружать их с диска и вынуждены постоянно держать в памяти.
См. выше, этот подход известен но это в общем то компромиссный вариант исправления перфоманса без существенной переделки дискового формата. Более прямой вариант - дизайнить дисковый формат которому не требуются такие костыли, имхо.
>> как у них расчистка места сделана. Плохо искал?
> что такое расчистка места? Дефрагментация что-ли? Тогда никак
Ну собственно CoW производит запись в сторону. Отсюда вытекает нужда стирать иногда старые данные, иначе место на томе закончится по очевидной причине. У саней в манах про алгоритмы всего этого вообще что-то ни звука. И кстати не вижу причин по которым нельзя сделать дефраг в процессе этого действа.
