назначен - где? чем? где это видно?

в *:500 видно

я понимаю, что udp-пакет можно просто послать без предварительных танцев, но как без этих танцев принять пакет на определенном порту?

что значит "в *:500 видно"? невооруженным глазом?

*:500 это последствие того что там bind() зазвали, передав ему порт 500

это я понимаю. где и чем мне предлагается увидеть "в *:500"?

я не понял

ну вот "в *:500 видно" - чем видно? каким инструментом? (я не знаю, как еще спросить)

как я могу определить, что программа ждет пакет на порту 500?

Вот так это выглядит после рестарта:

# service racoon restart
Stopping racoon.
Waiting for PIDS: 16100.
Starting racoon.
# sockstat|grep racoon
root     racoon     17286 4  stream /var/db/racoon/racoon.sock
root     racoon     17286 6  udp4   192.168.0.254:4500    *:*
root     racoon     17286 7  udp4   192.168.0.254:500     *:*

Вот так это выглядит после сессии:

# sockstat|grep racoon
root     racoon     16100 4  stream /var/db/racoon/racoon.sock

Чем и как мне понять, что на порту 500 ждут пакет, если sockstat'ом не видно, что ждут?

раз sockstat'ом не видно что ждут значит не ждут

Ну так о том речь и шла с самого начала. Я сразу еще вчера сказал, что в выхлопе sockstat открытые порты 500 и 4500 пропадают - мне стали говорить, что и без этого можно пакет ловить. Я и спросил - как?

ламерский вопрос: пару дней назад pkg из портов говорило что его надо обновить, сегодня говорит уже что не надо

передумал

Замечал ли кто, что если есть два ZFS-пула на независимых девайсах, и один загружен кучей мелких рандомных чтений, то и второй начинает тормозить?
Или мне кажется?

У меня вот есть ощущение, что когда торренты отдаются активно, то и всякие svn up src в домашнем каталоге становятся гораздо медленней (например, начинаются не сразу, долго висит в состоянии Updating '.' прежде чем начать и правда обновлять). При этом это происходит, повторюсь, на разных пулах и никак не связанных дисках.

Как будто он во что-то внутри кода ZFS упирается.

(как бы померять?..)

ARC наверное на оба пула общий

Ну, ARC общий, но казалось бы svn up на всём холодном не очень должен зависеть от кеширования… Хотя чёрт их знает сколько они раз по одним и тем же данным туда-сюда ходят…

dark@t460:~/svn/freebsd-current % ktrace -t n svnlite up
Updating '.':
At revision 359686.
dark@t460:~/svn/freebsd-current % kdump | wc
   37900  151600 2996698
dark@t460:~/svn/freebsd-current % kdump | awk '{print $NF}' | sort -u | wc
   15159   15159  948978

если я правильно всё понял 15к файлов потеребилось

сам не разбирался, но говорят, там всё печально со всякой метаинформацией или около того