Добавлено: 01 мар 2007, 16:19
фрибсд это очень круто чувак, но у меня линукс, имплификация nfs в котором может отличатся, особенно в тонкостях, с которыми у меня и проблемы.
Страница 2 из 2
Добавлено: 01 мар 2007, 16:23
во, еще вспомнил. проверь вот что. может быть такое, что на серваке запущен nfsd 4-ой версии, а утилита монтирования у тебя 3-ей (либо наоборот).
Добавлено: 01 мар 2007, 16:27
есть понятие стандартов. smb под виндовс, линукс и *бзд ведь универсальна. тоже самое и с nfs.tes+or писал(а):фрибсд это очень круто чувак, но у меня линукс, имплификация nfs в котором может отличатся, особенно в тонкостях, с которыми у меня и проблемы.
update: хотя если ты не про реализацию протокола, а про настройку этого всего, то истина на твоей стороне=)
Добавлено: 01 мар 2007, 23:24
я реализую или настраиваю?=)
умение расшарить папку в оффтопике мне никак не помогало написать конфиг для самбы, пришлось мануал читать, а протокол такойже стандартный=))
ближе к сабжу - четвертая версия нигде не вкомпилена в мое ядро, хотя клиент может реализовывать ее независимо от ядра(возможно). с другой стороны, в протоколе должно быть предусмотрено снюхивание касаемо версий, поэтому не думаю что если оно у меня уже смонтировалось, то дело в этом. другое дело что оно и монтируется то через раз..
*ушел читать маны дальше*
умение расшарить папку в оффтопике мне никак не помогало написать конфиг для самбы, пришлось мануал читать, а протокол такойже стандартный=))
ближе к сабжу - четвертая версия нигде не вкомпилена в мое ядро, хотя клиент может реализовывать ее независимо от ядра(возможно). с другой стороны, в протоколе должно быть предусмотрено снюхивание касаемо версий, поэтому не думаю что если оно у меня уже смонтировалось, то дело в этом. другое дело что оно и монтируется то через раз..
*ушел читать маны дальше*
Добавлено: 02 мар 2007, 00:57
http://nfs.sourceforge.net/nfs-howto/ar01s05.html
вот, приползу завтра на работу, попробую все что тут написано.
вот, приползу завтра на работу, попробую все что тут написано.
Добавлено: 02 мар 2007, 15:40
вобщем какой опыт я извлек:
само по себе ядро может монтировать только по 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)
т.е. использует третья версия протокола что не соответствует действительности.
само по себе ядро может монтировать только по 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)
т.е. использует третья версия протокола что не соответствует действительности.
Добавлено: 02 мар 2007, 17:51
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.
Добавлено: 02 мар 2007, 23:42
дада, у меня cервак висит на RPC, поддерживает 2ю и 3ю версию протокола и представляет из себя набор демонов nfsd, mountd, lockd, quotad и еще что-то. вроде как это юзерспэйс? если да, то как запустить ядерную версию в принципе? я много чего читал и различия нигде не акцентировались.
клиент же на уровне ядра принимает параметры из аргументов ядра при загрузке, а чем он монтирует через fstab и mount - я незнаю, ядро это или юзерспейс.
т.е. для начала я вообще немогу понять что такое демон на уровне ядра? это что-то запускается и обращается к какому-то вызову ядра поднимая на нем сервис. если да, то как определит что именно происходит, подъем сервиса в ядре или в юзерспейс демоне?
вывод о том, что ядерный демон сильно ограничен в опциях я сделал из того, что он просто отклонял аргументы ядра которые были заявлены как аналог опций для mount -t nfs и поддерживал только те, что описаны в /usr/src/linux/Documents/nfsroot.txt, но явно отклонял описанные в man nfs.
я полной растерянности и прострации, я решительно не могу понять что вообще происходит в моих системах, а это меня коренным образом не устраивает.
клиент же на уровне ядра принимает параметры из аргументов ядра при загрузке, а чем он монтирует через fstab и mount - я незнаю, ядро это или юзерспейс.
т.е. для начала я вообще немогу понять что такое демон на уровне ядра? это что-то запускается и обращается к какому-то вызову ядра поднимая на нем сервис. если да, то как определит что именно происходит, подъем сервиса в ядре или в юзерспейс демоне?
вывод о том, что ядерный демон сильно ограничен в опциях я сделал из того, что он просто отклонял аргументы ядра которые были заявлены как аналог опций для mount -t nfs и поддерживал только те, что описаны в /usr/src/linux/Documents/nfsroot.txt, но явно отклонял описанные в man nfs.
я полной растерянности и прострации, я решительно не могу понять что вообще происходит в моих системах, а это меня коренным образом не устраивает.
Добавлено: 05 мар 2007, 21:23
вобщем, что-то прояснилось, тут важно было успокоится и немного отвлечся. если не передавать по 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.
или нефига гнать на производителей и у меня руки кривые?
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.
или нефига гнать на производителей и у меня руки кривые?
Добавлено: 05 мар 2007, 21:32
tes+or, сетевушки - пробовать любые другие. DEC, за исключением одной глчной серии - очень приличные карточки. Но все бывает. Если закупатся - то искать intel.
Добавлено: 06 мар 2007, 00:48
что интел это круто, я вобщем догадываюсь, просто переспрашиваю на всякий случай, дело даже не в этом, дело в том, что стоит брать интел или всеже можно еще что-то покрутить кроме MTU?
и как поменять MTU при получении параметров по DHCP? в ядре указать где-то при компиляции? или в PXE? впрочем PXE это полюбому временное решение, полюбому надо брать интелы с вшитыми бутромами.
короче как тут лучше быть?
и как поменять MTU при получении параметров по DHCP? в ядре указать где-то при компиляции? или в PXE? впрочем PXE это полюбому временное решение, полюбому надо брать интелы с вшитыми бутромами.
короче как тут лучше быть?
Добавлено: 06 мар 2007, 10:35
tes+or, а что, по-твоем у интеля во вшитых бутромах что-то отличное от PXE ? 
PS: ну возьми произвольные другие карточки, хоть 8139D и проверь... Нужто нету под руками?
PS: ну возьми произвольные другие карточки, хоть 8139D и проверь... Нужто нету под руками?
Добавлено: 06 мар 2007, 12:55
ну, может там тоже PXE, но вроде как существуют и другие загрузчики.. неважно, важно чтобы работало, а работать оно будет.
сетевушку поменял на произвольную, на такую же via, как оказалось и о чудо(хотя никакого чуда) ОНО РАБОТАЕТ! проблема была в том, что я в DECовский драйвер вкомпилил всякие стремные эксперементальные фишки которые по видимому и производили глюки. похорошему багрепорт надо накатать, но я точно незнаю как это делать и куда, и не уверен что смогу толком описать проблему.. незнаю, братся ли, и так головной боли хватает. это популярный чип, стоит возится с багрепортом?
сетевушку поменял на произвольную, на такую же via, как оказалось и о чудо(хотя никакого чуда) ОНО РАБОТАЕТ! проблема была в том, что я в DECовский драйвер вкомпилил всякие стремные эксперементальные фишки которые по видимому и производили глюки. похорошему багрепорт надо накатать, но я точно незнаю как это делать и куда, и не уверен что смогу толком описать проблему.. незнаю, братся ли, и так головной боли хватает. это популярный чип, стоит возится с багрепортом?
Добавлено: 06 мар 2007, 13:21
Не, DEC нынче экзотика. Их давно и скупил интель.