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

Ну вот samba 4.6/4.7 - упирается в ядро CPU, насколько я вижу. 4.3 (которая у меня была побыстрее) - в pkg нет, собирать немножко лень.
4.8 - упирается хз во что, не вижу упора, но тем не менее.

С другой стороны Win10, совокуплено через асусовский свитч (но mbuffer-у свитч не мешал)

Спасибо за совет с lz4/нулями, докладываю:
samba 4.6, 4.7 (из настроек SO_RCVBUF=2097152 SO_SNDBUF=2097152 остальное все что пробовал - не влияет на производительность):
~660MB/sec read speed (копировал Windows Explorer, он побыстрее), smbd ложится на 100% CPU и все.

samba 4.8 (тот же конфиг): 800-810, может быть даже больше, smbd 130% CPU ну и видно что там worker threads запускаются.

Самбы 4.9 в портах отчего-то нет, хотя уже два месяца как вышла.

При этом Changelog у самбы не очень внятный, они пишут про новые features, а вот то что aio реализовали иначе в 4.8 - с большим трудом нашел.

В принципе, 800+ меня устраивает. То есть конечно у меня есть программы, которые умеют читать больше (FastRawViewer, если его кормить нежатыми сонями - гигабайта полтора/сек может выжрать), но в реальности это все уже не надо.

Хрен эту самбу разберет.
Ну то есть с пару лет назад я столкнулся с тем, что samba 4.3 работала быстрее, чем 4.4 (а более новых тогда вроде бы не было, или что-то было в бете), ну так с тех пор и работает у меня.

Но блин, 4.3 уже в портах нету, и не сравнить.

Если затюнить - заставить использовать мегабайтное окно TCP и пр.

Со стороны zfs достаточно одного hdd. Для чтения создать в датасете с lz4 большой файл забитый нулями или ещё быстрее будет читать большой sparse файл. Для записи подойдёт файл забитый нулями в датасет с lz4. На стороне win если нет быстрых nvme (или жалко) для чтения можно использовать diskspd.

Не хочу возиться с рамдиском, поэтому увидим когда полноценный массив (с L2) туда приедет.

Но вообще - ну скорее таки меньше.

Я бы и для плохо сжимаемых данных включал lz4. Впрочем для данного процессора лучше проверить.

У меня данные, за редчайшими исключениями, плохо сжимаемые. Соответственно, zfs-компрессия не используется.

И ещё момент касательно zfs send и компресии: когда я развлекался с этой темой пару лет назад, zfs send --compressed ещё не существовало даже в OpenZFS, хотя уже был фичереквест. Тогда для сжатых файловых систем zfs send безусловно распаковывал данные перед отправкой, так что в обратной компрессии перед выпуском в сеть был смысл для сжимаемых данных и незанятых ядер CPU.

Нынче уже есть zfs send -c и оно сжатые блоки данных посылает в сжатом виде, но вот блоки с метаданными оно AFAIK таки разжимает перед отправкой и если метаданных много... Можно потестировать.

Я имел в виду вот что:
Если я пускаю zfs send | ssh remote zfs recv
То где бы оно не сломалось, тут, там, посередине - достаточно проверить один код ошибки, если он не 0, то клеим ласты.

А если же мы к примеру запускаем как-то так (синтаксис условный, могу напутать с кавычками)
ssh remote "nс -l port | zfs recv" & # я кстати сходу даже не знаю можно ли так, но почему собственно и нет....
sleep 1;
zfs send | nc remote port

То вся логика обработки ошибок, количества мест их возникновения и проч - сильно усложняется в сравнении с one-liner.

А если я для сохранения 1-liner на своей стороне - на удаленную сторону привешу zfs recv в inetd.conf - то скрипты опять 1-liner, но вот обработка ошибок еще более усложняется.

Ну подождите: zfs send | { ssh remotehost zfs recv && touch $s; }
Это именно кормление zfs recv данными через медленный (в данном случае) ssh.

Оно у меня так сейчас примерно и работает, но проблема в том, что ssh на новом ящике - медленный.

Ну то есть наверное вы имели в виду "на удаленном хвосте запустить mbuffer -I | zfs recv && touch

Ну да, так можно, онанизм но можно.

> Проблема в том, что мне нужен именно remote shell, чтобы ошибки с удаленного конца ловить.

Ммм, а в чём проблема с ошибками?

s=/var/run/send.success
rm $f && zfs send | { ssh remotehost zfs recv && touch $s; }
if [ -e $s ]; then
success
else
failure
fi

У нас на линуксах в какой-то момент выяснилось, что rsh теперь тот же ssh...