статистика nfs

Подобного не знаю, можно включить debug nfs-сервера и потом разгребать логи.

http://prefetch.net/blog/index.php/2011/11/02/using-rpcdebug-to-debug-linux-n...

/proc/sys/sunrpc/nfsd_debug

примерно это мне и нужно, спасибо.

у меня еще один вопрос, если можно, я монтирую nfs как ro, файлы на шаре никогда не меняются, есть ли возможность настроить nfs так, чтобы при первом чтении файла он попадал в кеш и больше оттуда никуда и никогда не девался, до перезагрузки системы разумеется, даже при полнейшем разрыве соединения, даже при атомной бомбардировке, один раз прочитал с сервера и больше за этим файлом никогда на сервер не полез???

или нужно использовать какую-то другую fs???

может это поможет?

Но зачем?

затем что у меня грузятся тонкие клиенты с nfs, соответственно rootfs на сервере, она не меняется, а если грузятся разом 30 - 40 клиентов, то время загрузки приближается к часу, ниразу не дождался если честно, так вот если уменьшить количество обращений на сервер, то и время загрузки по идее уменьшится

это находил, усомнился, что смогу нормально прикрутить к скрипту init

Вроде как NFS не читает файл целиком, только запрошенную прикложением часть. Можно попробовать выкрутить actimeo, чтобы не было постоянных проверок.

А для бездисковых клинетов, ИМХО, лучше сделать урезанную корневую ФС, чтобы она целиком грузилась в их ОЗУ, чтобы «даже при атомной бомбардировке» у них были все важные файлы и команды, а не только то, что они успели использовать/закешировать.

А так, достаточно давно, я загружал 4 «бездисковых» машинки по NFS, чтобы запускать на них первый doom и небыло особых проблем. Возможно, что вы используете udp и потери пакетов дают такой результат, попробуйте NFS по tcp.

нет, использую tcp, однако это не сеть внутри vpn

у них были все важные файлы и команды, а не только то, что они успели использовать/закешировать.

сейчас так и есть, важные файлы в озу в виде squashfs, только он большой получился, я думал, что с nfs лучше получится, рассчитывал, что на стороне клиента будет кэш