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

Я ставил 8.1, штатным способом, через Bootcamp.

Результат так себе
- переключения видеокарт intel-nvidia не происходит, работает только nv и жрет батарею.
- bluetooth устройства (мышь эппловская, адын штук) каждый раз надо повторно спаривать

Десятка наверное тоже будет работать, но не проверял.

# uname -r
11.0-RELEASE-p1

Из dmu_zfetch.c:
/*
* This tunable disables predictive prefetch. Note that it leaves "prescient"
* prefetch (e.g. prefetch for zfs send) intact. Unlike predictive prefetch,
* prescient prefetch never issues i/os that end up not being needed,
* so it can't hurt performance.
*/
boolean_t zfs_prefetch_disable = B_FALSE;

/* max # of streams per zfetch */
uint32_t zfetch_max_streams = 8;
/* min time before stream reclaim */
uint32_t zfetch_min_sec_reap = 2;
/* max bytes to prefetch per stream (default 8MB) */
uint32_t zfetch_max_distance = 8 * 1024 * 1024;
/* max bytes to prefetch indirects for per stream (default 64MB) */
uint32_t zfetch_max_idistance = 64 * 1024 * 1024;
/* max number of bytes in an array_read in which we allow prefetching (1MB) */
uint64_t zfetch_array_rd_sz = 1024 * 1024;

Таки да, данная настройка в sysctl не выведена. Но я не вижу особого смысла её менять. Хотя если хочется можно перекомпилировать zfs.ko.

У меня пока всё работает на 10.1 и только сейчас попробую перейти на 11. Поэтому я "знаком" только с этими двумя версиями. Мой опыт подсказывает, что zfs спроектирована довольно "правильно". С неё можно выжимать довольно много для некоторых конкретных задач. Поэтому (моё личное мнение) отталкиваться нужно от производительности дисков, затем проверить сколько может система (процессор, память, чипсет, контроллер) прокачать одовременно относительно полной производительности дисков. Дальше оценить теоретический порог производительности конфигурации zfs (в твоём случае raidz2). Постараться приблизиться к нему и успокоиться :-).

id_distance у меня пока нет.
distance - оказывает понятное магическое действие.

Пойду FreeBSD обновлю до 11, посмотрим и на id_distance заодно.

Что бы не играть в пятнашки, приведу выдержки из описания работы zfetch от последнего автора mav@:
"Максимальное окно превыборки называется zfetch_max_distance (8MB) для данных и zfetch_max_idistance (64MB) для метаданных (в 10.3). zfetch_array_rd_sz это размер операций чтения выше которого prefetch не срабатывает, предполагая что приложение и так указало весь размер данных что ему нужен и больше читать не будет (спорное мнение как по мне)."
Под zfetch_max_idistance понимается:
"Делается превыборка indirect blocks необходимых для доступа к следующим 64MB данных. На практике это значит чтение наперед всего несколько блоков метаданных, но существенно повышает скорость линейных операций, как чтения так и записи, так как к моменту запроса сразу известно откуда читать и куда писать, и можно сразу слать запрос."
По поводу роста окна предвыборки:
"Увеличивает плавно, но довольно резко -- удваивает окно при каждом
попадании, причем этот алгоритм в новом префетчере поменялся."
От себя добавлю.
max_streams - количество одновременно поддерживаемых потоков чтения, поэтому от изменения их количества скорость последовательного чтения не изменяется. При бездействии (отсутствии чтения) более 2 сек (min_sec_reap) поток из zfetch удаляется.
И ещё, так как zfs претендует на роль универсальной файловой системы, то в настройках по умолчанию выбирается компромис для применения в разных сценариях. Поэтому нужно учитывать, что улучшая в одном месте можно нарваться на засаду в другом.

О, fetch_max_distance сильно помогает, прям в разы. 550 стали читать (и 650 писать)

Не было печали...

Очень подробно функционал Кловера расписан, собственно, «от автора» (главного программера, если быть точнее) здесь в PDF:
applelife.ru/threads/clover.42089/
Там очень много крутилок набралось за всё время (и будет набираться с выходом новых осей), но если последовательно подобрать для себя рабочую конфигурацию и оформить всё это в .plist для конкретного железа — работает как часы.

Ну вот ты продаёшь (продавал) объективы как недостаточно резкие на той самой A7r, а тут у каких-то дешёвых стёкол — запас в несколько раз показан.

А у тебя эту статью обсуждали?
http://vgrin.host56.com/photo/articles/pixels/index_r.html
Что-то я вижу там прямое противоречие со всем, что читал об объективах. В том числе и у тебя. Но в чём подвох — понять не могу.

А, понятно.
Просто сейчас из яблочных поделий ноуты- это явно лучшее (правда последний... гхм...).
Тем более, что под linux'ом большинство ноутов быстро выжирают батарею, а windows использовать противно уже.

А ноут их чего не купил? Как раз ещё старые остались, со всеми разъёмами. Ноуты уж больно хороши (железом).

У меня HBA может маленько убавлять. Т.е. на терабайтниках старых он дает на ~10% меньше адаптека.
На 6T - не сравнивал.

Ну, основатель PayPal - выходец из дружной семьи советских людей...

sysctl -a | grep zfs :-))) (это конечно издевательство делать доступным столько настроек).
Ещё раз повторюсь я не разбирался с raidz, но довольно глубоко просмотрел цепочку чтения с mirror, поэтому это гарантированно касается только страйпа из зеркал.
Допустим нужно настроить максимальную скорость последовательного чтения.
Префетчинг - сюда я сильно не влазил, но окно префетчинга для каждого потока в FreeBSD 11 сделали 8MB (в FreeBSD 10.1 было 256 блоков (recordsize), как и в Ubuntu 16.04). Для насыщения всех дисков в пуле (добиться отсутствия простоев) желательно создать очередь чтения к каждому диску. А если дисков много ;-). Например, увеличивая окно до 32MB добавляем 10-20% производительности последовательного чтения.
Алгоритм балансировки зеркала - здесь немного посложнее, но скажу, что немного подправив алгоритм можно получить ещё плюс 20-30%. Кстати, в Ubuntu 16.04 остался старый алгоритм балансировки зеркала "по загрузке" и старые настройки окна префетчинга. Как результат на 1MB recordsize неприлично большой выигрыш в производительности, хотя при других значениях recordsize имеется отставание от FreeBSD.
Шедулер ввода-вывода. Настройка длины активной очереди асинхронного чтения (чтение данных префетчинга) тоже влияет. Но я впоследствии отказался от этой настройки.
Важен размер recordsize. И не всегда больше значит лучше :-). Я остановился на 128kB.
Также общее правило - на диски нужно писать необходимый и достаточный минимум информации что бы головки дисков не летали над дырами (настройки sync, logbias, redundant_metadata).