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

>> geom stripe (freebsd) транслирует TRIM (delete) дальше на провайдеров?

Транслирует и FLUSH тоже.

Кстати, в zfs по умолчанию на основной пул (обычно hdd) шлются DELETE (TRIM). Вроде как не критично, но смотрел не на сильно заполненном пуле. Возможно на сильно заполненном - это как-то будет лишним :-). Поэтому vfs.zfs.trim.enabled=0. Зачем слать лишние команды :-).

>> А как вы "скорость ARC" оцениваете?

Оценка была не скорости ARC, а объёма прочитанных данных. Объём файла 32768MB. Объём метаданных на данном датасете приблизительно 14MB. Recordsize на данном датасете 64kB. Размер в 64kB был выбран (насколько я правильно понял из исходников) исходя из размера блока в 64kB на L2ARC. Как я понял меньшие recordsize или группируются или пишутся с потерей пространства до 64kB. Объём прочитанных/записанных данных можно брать из iostat, но я использую свой geom c выдачей статистики по всем операциям (READ, WRITE, DELETE, FLUSH). Кстати, при добавлении L2ARC ssd (точнее выделенное пространство) полностью очищается (TRIM). Также он очищается при экспорте/импорте и я предполагаю при загрузке системы. Здесь разработчики молодцы - сделали как положено :-). Надеюсь и при замещении блоков в L2ARC тоже будут использовать TRIM. На счёт дополнительного объёма для обслуживания L2ARC в курсе, но не 12GB же :-). Вообще интересно наблюдать как в top менются MFU и MRU :-).

>> Ну типа "если диски - не самое медленное место /а сеть - медленнее и читают не на полной скорости/ - давайте с них тоже почитаем"

Интересное предложение/предположение :-).

Сегодня заново прочитал вчерашние тестовые файлы. Все файлы размером 32GB. Первые два были записаны в пул до установки L2ARC и по ним производилось только чтение (многократное :-)). Третий файл был записан в пул после установки L2ARC и во время записи был в полном объёме помещен в L2ARC. Скорости и откуда читались данные:
1 - 169MB/s (43% hdd, 57% ssd, 0% ARC);
2 - 344MB/s (3% hdd, 97% ssd, 0% ARC);
3 - 420MB/s (0% hdd, 99,8% ssd, 0,2% ARC).
Самое интересное - первый файл читался намного чаще других :-). Ещё один интересный вывод - при чтении файла больше половины (57%) из ssd скорость чтения возросла незначительно (всего на 4%). L2ARC не заполнен (размер ssd - 120GB), поэтому вытеснений из него не было. Также возник вопрос, а что находится в ARC(12GB) :-) ? Последие 40-50 раз читались только эти три файла.

Непонятная история.

У меня же на двух портах 10G рабочей станции - два FreeBSD-ящика.

Вот на том линке, который "быстрый NAS" - убираю AIM и "начинает входить быстро", 1+GB/sec пока влезает в кэш на приемной стороне.

На другом - убираю AIM и становится медленнее.

Разница в том, что на "быстром NAS" стоит карточка с прошивкой "как из китая приехало" (я даже версию не смотрел), а остальные две карты - перешиты на последнюю фирмварь, без этого на них ругалось про checksum error.

Загадочная вещь этот ваш 10G

Если я правильно помню, то Intel X540 (как и у меня)

Я знал, что винда виновата... отключил на интерфейсе в винде "Interrupt Moderation Rate" (--> Off), сразу чтение зашкалило за гигабайт с рамдиска.

Паритет?
10Gb - сеть и ~1Gb SSD-страйп?
;-)

Страйп есть (даже из трех, но третий сильно медленнее), выдает 920Mb/sec
Это быстрее дисков даже по bw, не говоря про latency - потому и хочется его использовать.

а ТЗ простое - хочется счастья, даром, чтобы никто не ушел

С одной стороны, стенд лепим из "верёвок" и палок.
С другой, одиночный SSD не прокачивает имеющийся сетевой линк (страйпа 2*SSD нет ведь?).
И с третьей, ... Кажется владелец блога незаметно для самого себя вляпался в классическую западню скоростей:
тормозит сеть (1Gb/s, если кто забыл) - меняем сетевое железо;
тормозит дисковая подсистема, меняем и оптимизируем контроллеры и ФС (и её опции);
снова "узкое горлышко" - сеть -- обновляем подсистему сети;
ЁКЛМН! снова "диски тормозят"! ...
...
... особенно учитывая "апгрэйд почти даром". ;-)

Может, уже имеет смысл сформулировать ТЗ, ... или наплевать на затраты?

Моё дилетантское ИМХО.

Боюсь, тут гамма-лазер нужен будет

Вы серьёзно??!
Это ж какие частоты нужны!!... И какая ширина канала!
Или Вы в далёком будущем живёте? ;-)

а почему именно NVMe? чем оно от pci-e отличается? )

Алгоритм кэширования по чтению совершенно не похож на применяемые в flashcache, bcache, dm-cache. Он не предсказуем, но похоже имеет свои плюсы :-).
Он называется ARC (Adaptive Cache Replacement), собственно, и хорошо описан в оригинальной статье. Это удачный гибрид LRU и MRU, самобаланчирующий сколько процентов места отдать LRU, а сколько MRU.

Не знаю что с bcache и dm-cache‚ но flashcache — всего лишь LRU, причём, что важно, не просто LRU, а всего 4-way associative (каждый блок может попасть всего в 4 места в кэше, а не куда угодно), а ARC в этих терминах полностью ассоциативный (как и кэши в памяти).

Ну в общем, да, как-то так.