Netware lockups met OSX-NFS clients

[Loesje]

Ik begin echt wanhopig te worden...

Ik heb hier een nw5.1sp5 server met NFS 3.0sp4.

Mac-osX clients die gebruik maken van NFS-shares.

Nu werkt dat wel, maar na ongeveer een a twee dagen, geeft pkernel de volgende fout: 440: RPC/UDP receive queues are full, packet dropped.

Die melding komt twee keer per minuut en de server hangt. Zodra je een module of iets anders probeert te loaden/unloaden doet hij niets meer. Extra console opstartten kan, maar downen of een ander commando en het de extra console bevriest ook. Zelfs via de debugger is zijn de volumes niet te unmounten en een hard-boot is de enige oplossing.

Wat er gebeurt is dat er 'incorrecte' UDP-pakketjes verstuurd worden. RPCBSTUB.NLM (onderdeel van pkernel) kan ze niet verwerken, ze worden pas na een te lange timeout gediscard, en ondertussen lopen de receive-buffers vol.

De receive buffer vergroten tot maximale grootte heeft als enige effect dat de server het zo'n 4 dagen uithoudt, voordat hij neergaat. Kan ik die timeout ergens instellen?

Novell zelf zegt in de handleidingen dat de illegale pakketjes met een lan-analyzer opgespoort moeten worden. Maar ik weet waar de (meesten) vandaan komen: de MAC's. Het probleem dat ik heb is er volgens Novell ook wel eens met solaris-clients geweest, maar de fix daarvoor was aan de solaris-kant.

Omdat ze hier de afgelopen weken tegen deadlines aanzaten, kon ik het systeem niet grondig onder handen nemen. Er werd 24/7 in ploegendiensten gewerkt. Maar nu ze klaar zijn kan ik wat proberen.

Ik heb geprobeerd om de clients nfs over tcp te laten gebruiken en de server ook alleen op TCP in te stellen.
Dat kan al niet, omdat Netware blijkbaar mountd niet over TCP ondersteunt, maar alleen over UDP. (Volgens rpcinfo wordt mountd niet aan TCP gebind.)
Nu is dat op te lossen door de clients te laten mounten via UDP maar verder via TCP te laten lopen.

Dat werkt, alleen: als ik een share op een Mac-client nu UNmount, abend nfsserv, en hangen alle nfs-shares op de andere clients.

Novell heeft wel een oplossing voor instabiele TCP-NFS: gebruik UDP i.p.v. TCP.

Iemand een id?

[Verwijderd]

Tja... even snel een idee.....

Je gebruikt een Linux-pc als gateway.... Linux-pc die je via nfs shared maakt (of appletalk als je wilt) die via ncpmount een Novell-volume mount. De dir waarin je dat Novell-volume mount is dan ook voor de clients die aan die Linux-bak attachen zichtbaar.

Linux is stabiel, Novell dan ook... ik denk wel dat het kan. Heb alleen zelf nog problemen om via ncpmount nss-volumes te mounten, maar ook dat zou moeten kunnen.

[Loesje]

Tja.. zou kunnen. Nu draaien hier alleen Novell en FreeBSD servers, die niet zoiets als ncpmount hebben. Maar een linux bak is zo neergezet. Blijft wel dat de performance dan omlaag gaat, en aangezien het om zwaar DTP-werk gaat draai ik het liever direct vanaf Novell.
Misschien dat ik gewoon voor het alternatief moet gaan en de mac's op een FreeBSD machine laten werken.

[Verwijderd]

Precies.... zet dat spul voor de macs gewoon apart op je FreeBSD-bakje... wel lastig voor het backuppen... kun je via een auto-ftp-sessie ('s nachts voor het backuppen) copieren naar je Novell-server...

[Loesje]

Is echt geen feest. Want hoe komen de win2k clients vervolgens bij die data? De data van een dag eerder is echt niet voldoende. Misschien dat ze op het novellnfs-forum nog iets weten. Ik bedoel: NFS moet toch kunnen werken?

[Onno]

Heb je al geprobeerd NFS versie 2 te gebruiken ipv 3? (of andersom, weet niet welke versie je nu gebruikt )

[Verwijderd]

Die win2k-clients? Heeeel simpel via samba op de FreeBSD-bak! Dat met ftp stelde ik alleen voor om vooraf aan her backuppen die DTP-files op de Novell-server te dumpen. Puur voor de backup.
Dus de mac's op de FreeBSD-server laten werken en de win-pc's op Novell en FreeBSD. Mooi toch?

[Loesje]

Nee. Ik ben juist blij dat het hele netwerk SMB-vrij is. Low-cost is hier een eerste vereiste, bandbreedte is zeldzaam. Geen smb-broadcast-zooi scheelt enorm in de performance van het hele netwerk.

Daarnaast moet ik die mappen dan gaan mounten in het Novell-login-script? Ook de load-balancing moet dan op de schop. In mijn ogen is echt een pleister-oplossing, maar toch bedankt.

Ik ben er inmiddels achter dat free-bsd-clients wel zonder problemen TCP kunnen mounten. Waarschijnlijk zit de fout dus aan de OS-X kant. Ik ga maar eens proberen om die naar OS-X 10.2 te upgraden. En ik heb de abend.log naar Novell gestuurd, misschien komt daar iets nuttigs uit. De abend vind iedere keer plaats met exact dezelfde registerwaarden, op exact hetzelfde stukje code.

Ik ben eigenwijs en wil het eigenlijk op een server kunnen draaien. Ik bedoel, dat moet toch kunnen?

En Onno, ik gebruik nu versie 2, omdat versie 3 in eerste instantie niet lekker werkte op de OS-X clients. Maar ik zal versie 3 nog eens proberen.

[Verwijderd]

Loesje, je hebt gelijk.... ik ben alleen bang dat Novell's oplossing wel eens lang kan duren... en dan ga ik vlug aan een workaround denken...

Ik ben heel benieuwd wat je gaat doen en hoe je het uiteindelijk oplost...

[Loesje]

Voor de geinteresseerden: ik heb het opgelost.

De pkernel.nlm en rpcbstub.nlm heb ik vervangen voor een oudere versie, namelijk die uit SP3. Ik kwam op het idee door dit linkje. Ik ging ervan uit dat die fix ook wel in de nieuwere pkernel's zou zitten. Niet dus. Die fix is er blijkbaar later weer uitgehaald.

Ik ben in ieder geval weer happy! Een uptime van 6 dagen!

[Verwijderd]

Tja... shit happens... mooi dat het opgelost is... nu nog een nulletje achter de uptime !!