Свежие комментарии

Там гораздо больше, чем только WITNESS/INVARIANTS. В GENERIC/head:

# For full debugger support use (turn off in stable branch):
options BUF_TRACKING # Track buffer history
options DDB # Support DDB.
options FULL_BUF_TRACKING # Track more buffer history
options GDB # Support remote GDB.
options DEADLKRES # Enable the deadlock resolver
options INVARIANTS # Enable calls of extra sanity checking
options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
options WITNESS # Enable checks to detect deadlocks and cycles
options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones

Где - "там"?
Вы говорите о каком-то наборе кадров, но я не понимаю о каком.

upd: скриншот выше по ссылке увидел, но сами кадры бы....

test_all - в предыдущий раз я давал файл-задание fio для одновременного последовательного чтения со всех дисков.
С записью согласен. Верхний потолок - производительность самого медленного диска в raidz2 умножить на количество дисков в raidz2 минус 2. И ещё всё таки минус затраты на запись метаданных. Здесь наверно можно поиграться их уменьшить, но выигрыш наверно будет исчисляться единицами процента. При измерении dd нужно учитывать, что после показа завершения записи на диски может продолжаться запись ещё несколько секунд (writeback).
По чтению почти согласен :-). Думаю нужно обращать внимание не на метаданные, а на расположение контрольных блоков. Моё предположение, что для конфигурации raidz2 в 7 дисков потолок последовательного чтения будет приблизительно равен потолку записи или немного больше, а вот для 6 (что то мне подсказывает) возможно и значительно больше потолка записи.

zfs позиционируется, как универсальная файловая система. Поэтому должна бы в принципе настраиваться под любую нагрузку. По моему же личному мнению/опыту некоторые сценарии/патерны на ней скажем так "не очень". Возможно моё мнение и субъективно :-).
Для настройки последовательного чтения в zfs разработан блочный префетч (который всегда выключен по умолчанию), довольно навороченный файловый префетч. Для зеркала предусмотрено/разработано почти удвоение скорости последовательного чтения. В шедуллере выделена отдельная очередь для предвыбираемого последовательного чтения. Всё это регулируется/настраивается. Теперь вопрос - у какой файловой системы есть такие развитые средства и самое главное какая комбинация (файловая + рэйд) на любой операционной системе может дать сопоставимый результат по скорости последовательного чтения? Вот для примера, прямо сейчас с работающего круглосуточно пула (из 4 дисков - 2 диска со скоростью в начале 195MB/s и два 175MB/s) холодное последовательное чтение большого (32GB) файла 562MB/s, одновременное последовательное чтение двух больших (по 32Gb) файлов 300+290MB/s, повторное чтение (метаданные в кэше) - 640MB/s и 350+342MB/s соответственно.

Еще одним блоком четности на отдельном шпинделе, то есть это "как RAID6"

Так там же серия кадров снятая с зафиксированными диафрагмой и выдержкой (на скриншоте видно экспопару), меняется только ИСО. Я абсолютно согласен что для сравнения это не лучший кадр. Но учитывая что камерный джипег на 6400 выглядит заметно светлее кадра на 3200, а в raw он примерно одинаковый по экспозиции (глянул и в RawDigger) - странно в общем.

CURRENT ведь для любителей нетрадиционного секса. А у Вас "боевой "сервер"".
Опытные товарищи строго рекомендуют сидеть на предыдущей мажорной версии FreeBSD.

Сомнительно, чтобы родная для Солярки ФС затачивалась на последовательное чтение.
Особенно если вспомнить про 16 головок на 1 шпинделе... Про SSD вообще молчу, но для них оптимизаций, может, и нет ещё.

Я не знаю что такое test_all.

6/4, 7/5 это вот что:
- в гипотетической идеальной ситуации мы можем получить при записи на 7-дисковый массив "скорость 5x одиночный диск" (плюс-минус метадата). И примерно столько и получаем, кстати.
- при чтении, если вдруг случайно метадата разлеглась так, что мы ее никогда не читаем - в 7/5 раза быстрее должны бы читать

Я завтра сведу это в таблицу и тогда зарепорчу уже.

Я тут весь вечер сижу - скачать memstick-образ, записать на флешку, забутиться, создать пул, прогнать 4 (8 тестов).
10.1, 10.2,10.3,11.0, 12-20161130

А вот это я бы уже репортил. Учитывая, что ZFS они стараются держать синхронным между ветками и эта регрессия может легко попасть и в 10 и в 11.

А в 12-current сломан ZFS целиком, см. красное предупреждение в посте.

Под полной производительностью пула имелся в виду результат test_all на тестируемом участке. Относительная производительность - это % от неё.
Картинка распределения данных в raidz по дискам от разработчиков довольно известная, вроде даже ты :-) ссылку в этом блоге когда-то давал. Наверняка можно посмотреть распределение блоков по zdb, но наверно твоих результатов достаточно для понимания.
Можно ещё перефразировать - какой результат тебя бы устроил :-) ?
Что имелось ввиду под "6/4 и 7/5"?

Я вопроса не понял, что такое "производительность чтения относительно полной производительности пула"?
raidz2 относительно страйпа что ли?

Для ответа на этот вопрос надо знать внутреннюю организацию данных в raidz2. То есть вот условно говоря, если *вдруг* нам удается организовать данные так, что контрольные суммы и данные лежат "целыми дорожками" (ну там для 7 дисков, на каждом диске "5 дорожек данных, 2 дорожки контрольных сумм", то при такой организации оверхеда можно практически избежать: при нормальном чтении мы никогда не читаем.

Может ли такое наблюдаться на практике - я не знаю. На практике я вижу для некоторых (не самых новых :) версий FreeBSD превышение скорости чтения над записью на 12-14% (для мегабайтной recordsize). В идеальном случае были бы 6/4 и 7/5, такого нет и близко.