[Services For Unix] NFS client remount regelmatig

[Mr. B.]

Een probleem voor diegenen die ervaring hebben met Services For Unix, en dan met name de NFS client...

Server:
- Debian GNU/Linux ("Spitfire")
- nfs-common, nfs-kernel-server en nis packages geïnstalleerd
- 3 exports: /home, /raid/www en /raid/data

Client:
- WinXP Pro SP2 ("Mustang")
- Services For Unix 3.5 geïnstalleerd, onderdelen: User Name Mapping en Client for NFS
- User Name Mapping gebeurt d.m.v. NIS

Om de onvermijdelijke vraag "waarom geen Samba?" alvast te beantwoorden: performance. Ik heb van alles geprobeerd om Samba te tunen, maar ik kreeg het zaakje maar niet op een degelijke snelheid. De leessnelheid vanaf een NFS share is hier op een gigabit netwerk ongeveer 50% hoger dan via Samba (en praktisch net zo hoog als de snelheid via FTP).

Inhoud van /etc/exports op de server:

code:

/home      mustang(rw,sync,no_subtree_check)                  thunderbolt(rw,sync,no_subtree_check)
/raid/data mustang(rw,sync,no_subtree_check,mountpoint=/raid) thunderbolt(rw,sync,no_subtree_check,mountpoint=/raid)
/raid/www  mustang(rw,sync,no_subtree_check,mountpoint=/raid) thunderbolt(rw,sync,no_subtree_check,mountpoint=/raid)

Op /raid is, hoe verrassend, een RAID array gemount (Linux software RAID 1, maar dat lijkt me irrelevant).

Gemounte shares op client "Mustang":

code:

C:\>mount

Local    Remote                                 Properties
-------------------------------------------------------------------------------
D:       \\spitfire\raid\data                   UID=1000, GID=1000
                                                rsize=32768, wsize=32768
                                                mount=soft, timeout=0.8
                                                retry=3, locking=yes
                                                fileaccess=770, lang=ANSI
                                                casesensitive=no
H:       \\spitfire\home                        UID=1000, GID=1000
                                                rsize=32768, wsize=32768
                                                mount=soft, timeout=0.8
                                                retry=3, locking=yes
                                                fileaccess=770, lang=ANSI
                                                casesensitive=no
W:       \\spitfire\raid\www                    UID=1000, GID=1000
                                                rsize=32768, wsize=32768
                                                mount=soft, timeout=0.8
                                                retry=3, locking=yes
                                                fileaccess=770, lang=ANSI
                                                casesensitive=no

De shares zijn dus keurig gemount; alles werkt. Probleem is dat het starten van een executable vanaf een NFS share vaak lang duurt (maar uiteindelijk werkt het wel). Slechts af en toe treedt hetzelfde effect ook op bij het simpelweg browsen op de betreffende network drive; meestal lukt dat wel meteen. Het probleem treedt op bij alledrie de shares.

Even een greep uit /var/log/messages op de server, van een moment waarop ik een executable op D: probeerde te starten:

code:

Jan 26 01:39:13 spitfire rpc.mountd: export request from 10.0.10.4
Jan 26 01:39:13 spitfire rpc.mountd: export request from 10.0.10.4
Jan 26 01:39:13 spitfire rpc.mountd: refused mount request from mustang.home.lan for /raid (/): no export entry
Jan 26 01:39:14 spitfire rpc.mountd: refused mount request from mustang.home.lan for /raid (/): no export entry

Voor de duidelijkheid: 10.0.10.4 is het IP adres van de XP client "Mustang".

Twee zaken/problemen vallen op:

1. De export requests. Die zie ik heel vaak terugkomen. Waarom wordt dat op de client niet gecached? Waarom moet het überhaupt nog opgevraagd worden als de betreffende share gewoon via z'n gemapte driveletter gebruikt wordt?
2. Het proberen te mounten van /raid. Die dir is helemaal niet geshared! Het is echter wel de parent dir van de share die (let wel: via z'n driveletter) benaderd wordt.

Deze 2 punten doen mij vermoeden dat het probleem bij de NFS client ligt en niet bij de server, vandaar dat ik dit in WOS post.
[Edit]
Bij nader inzien hoort het eigenlijk meer in Network Troubleshooting thuis... verplaats maar s.v.p.
[/Edit]

Het lijkt er dus op dat de NFS client periodiek (na een bepaalde tijd? na een bepaalde hoeveelheid dataverkeer?) z'n shares wil remounten, of de shares alsnog via "server:/directory" of "\\server\directory" probeert te benaderen i.p.v. via hun gemapte driveletter. Dat gaat daarbij dus ook nog eens verkeerd, aangezien er een poging wordt gedaan om een directory te mounten die niet geshared is.

Kortom, eh... help!

[ Voor 3% gewijzigd door Mr. B. op 28-01-2006 00:01 ]

[Mr. B.]

Kom net uit de kroeg, maar ben nog (net ) nuchter genoeg om te zien dat er nog niet gereageerd is... ergo: *kick*

[Mr. B.]

*bump*

[Mr. B.]

En nog een keer... er moet toch wel iemand zijn die hier iets meer van weet?

[Thijs B]

Denk dat je deze post beter in non-windows had kunnen zetten en volgens mij worden nfs clients nog maar zelde gebruikt.

Op het werk gebruiken we al heel lang Omni-NFS-X Enterprise volgens mij is daar ook een 30 dagen versie van, misschien dat het met een andere nfs client wel goed gaat. goede nfs clients voor 2000/xp zijn schaars....