nfs глючит

[tes+or]

фрибсд это очень круто чувак, но у меня линукс, имплификация nfs в котором может отличатся, особенно в тонкостях, с которыми у меня и проблемы.

[soko1]

во, еще вспомнил. проверь вот что. может быть такое, что на серваке запущен nfsd 4-ой версии, а утилита монтирования у тебя 3-ей (либо наоборот).

[soko1]

фрибсд это очень круто чувак, но у меня линукс, имплификация nfs в котором может отличатся, особенно в тонкостях, с которыми у меня и проблемы.

есть понятие стандартов. smb под виндовс, линукс и *бзд ведь универсальна. тоже самое и с nfs.

update: хотя если ты не про реализацию протокола, а про настройку этого всего, то истина на твоей стороне=)

[tes+or]

я реализую или настраиваю?=)

умение расшарить папку в оффтопике мне никак не помогало написать конфиг для самбы, пришлось мануал читать, а протокол такойже стандартный=))

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

*ушел читать маны дальше*

[tes+or]

http://nfs.sourceforge.net/nfs-howto/ar01s05.html

вот, приползу завтра на работу, попробую все что тут написано.

[tes+or]

вобщем какой опыт я извлек:
само по себе ядро может монтировать только по 2ой версии протокола, только по udp и, кажется, только а sync моде, другие опции касаемо этих вещей оно не принимает. размеры wsize и rsize позволяют варировать тормоза в пределах от очень больших до очень-очень больших. и ладно бы, ядро быть может допустимо грузить и с тормозами, но проблема в том, что когда инит скрипты делают перемонтирование, они его на самом деле не делают, смотрел в логах. я там явно указал третью версию протокола и еще много чего - фигу, оно по факту туда даже не смотрит. почему так может быть?

таким образом мы имеем 2 проблемы:
1. после монтирования ядром оно долго сыплет:
nfs: server 192.168.111.200 not responding, still trying
nfs: server 192.168.192.200 OK

много раз в различных сочетаниях, при этом сильно тормозя
2.когда оно говорит что делает ремаунт в rw, оно на самом деле этого не делает. хотя в выводе mount говорит что рут смонтирован так:
192.168.111.200:/diskless_gentoo on / type nfs (rw,hard,intr,nolock,nfsvers=3)
т.е. использует третья версия протокола что не соответствует действительности.

[Llama]

tes+or, нет, не верено. Ядро может монтировать хоть четвертую версию протокола, ежели оно собрано с такой поддержкой. По умолчанию "NFS client" в ядре подразумевает тертью версию протокола AFAIK. А вторая версия - это у вас от кривизны _сервера_

Код: Выделить всё

Description: Kernel NFS server support
 Use this package if you want to use the kernel-mode NFS server.
 The user-mode NFS server in the "nfs-user-server" package is slower
 and less featureful but easier to debug than the kernel-mode server.

Description: User space NFS server
 This package contains all necessary programs to make your Linux machine act
 as an NFS server, being an NFS daemon (rpc.nfsd), a mount daemon (rpc.mountd).
 .
 Unlike other NFS daemons, this NFS server runs entirely in user space.  This
 makes it a tad slower than other NFS implementations, and also introduces
 some awkwardnesses in the semantics (for instance, moving a file to a
 different directory will render its file handle invalid).
 .
 There is currently no support for file locking.

[tes+or]

дада, у меня cервак висит на RPC, поддерживает 2ю и 3ю версию протокола и представляет из себя набор демонов nfsd, mountd, lockd, quotad и еще что-то. вроде как это юзерспэйс? если да, то как запустить ядерную версию в принципе? я много чего читал и различия нигде не акцентировались.

клиент же на уровне ядра принимает параметры из аргументов ядра при загрузке, а чем он монтирует через fstab и mount - я незнаю, ядро это или юзерспейс.

т.е. для начала я вообще немогу понять что такое демон на уровне ядра? это что-то запускается и обращается к какому-то вызову ядра поднимая на нем сервис. если да, то как определит что именно происходит, подъем сервиса в ядре или в юзерспейс демоне?

вывод о том, что ядерный демон сильно ограничен в опциях я сделал из того, что он просто отклонял аргументы ядра которые были заявлены как аналог опций для mount -t nfs и поддерживал только те, что описаны в /usr/src/linux/Documents/nfsroot.txt, но явно отклонял описанные в man nfs.

я полной растерянности и прострации, я решительно не могу понять что вообще происходит в моих системах, а это меня коренным образом не устраивает.

[tes+or]

вобщем, что-то прояснилось, тут важно было успокоится и немного отвлечся. если не передавать по DHCP параметр
option root-path "/diskless_gentoo/";
то он начинает слушать то, что я передаю ему в параметрах ядра. но смена версии протокола ничего не дала, хоть, в общем случае это хорошо что я разобрался, но тормоза как были так и остались.

потом я подумал и внимательнее посмотрел в вывод ifconfig:

eth0 Link encap:Ethernet HWaddr 00:80:AD:B6:0D:41
inet addr:192.168.111.200 Bcast:192.168.111.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1024 Metric:1
RX packets:725161 errors:1 dropped:0 overruns:0 frame:0
TX packets:2885 errors:292775 dropped:0 overruns:0 carrier:292775
collisions:0 txqueuelen:1000
RX bytes:129160802 (123.1 Mb) TX bytes:1604342 (1.5 Mb)
Interrupt:11 Base address:0xc000


это errors - не с проста, подумал я и начал крутить MTU, потому что о том, что крутить еще - незнаю. помню у меня уже был такой отстой с самбой, где у меня скорость с огромным трудом переваливала через 1.5 мегабайта в секунду, но то была самба, которая работает через TCP и, следовательно, менее чувствительна к ошибкам eth уровня. покрутил и, как и тогда, хорошо заработать оно конечно не заработало, но разница точно наблюдается.

на сервере у меня:
00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 11)

а а на клиентах:

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

2. 00:0b.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 86), это теперь, тоже черт его знает, что скажете?

надо что-то крутит и настраивать или просто сетевушки плохие и их надо на что-то поменять?

если да, то скажите точно на что? думается в сервер имеет смысл поставить гигабит и использовать свитч с одним гигабитным портом и 4-7 100мегабитными? если да, то опять-таки, порекомендуйте быстрые и безглючные чипсеты и производителей, чтобы никаких errors.

или нефига гнать на производителей и у меня руки кривые?

[Llama]

tes+or, сетевушки - пробовать любые другие. DEC, за исключением одной глчной серии - очень приличные карточки. Но все бывает. Если закупатся - то искать intel.

[tes+or]

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

и как поменять MTU при получении параметров по DHCP? в ядре указать где-то при компиляции? или в PXE? впрочем PXE это полюбому временное решение, полюбому надо брать интелы с вшитыми бутромами.

короче как тут лучше быть?

[Llama]

tes+or, а что, по-твоем у интеля во вшитых бутромах что-то отличное от PXE ?
PS: ну возьми произвольные другие карточки, хоть 8139D и проверь... Нужто нету под руками?

[tes+or]

ну, может там тоже PXE, но вроде как существуют и другие загрузчики.. неважно, важно чтобы работало, а работать оно будет.

сетевушку поменял на произвольную, на такую же via, как оказалось и о чудо(хотя никакого чуда) ОНО РАБОТАЕТ! проблема была в том, что я в DECовский драйвер вкомпилил всякие стремные эксперементальные фишки которые по видимому и производили глюки. похорошему багрепорт надо накатать, но я точно незнаю как это делать и куда, и не уверен что смогу толком описать проблему.. незнаю, братся ли, и так головной боли хватает. это популярный чип, стоит возится с багрепортом?

[Llama]

Не, DEC нынче экзотика. Их давно и скупил интель.