Eerst moet je een kernel hebben met het NFS file systeem erin gecompileerd of als module laadbaar. Dit is geconfigureerd voordat je de kernel compileerd. Als je nog nooit een kernel hebt gecompileerd moet je misschien in de Kernel HOWTO kijken en het uitvissen. Als je een hele coole distributie (zoals Red Hat) gebruikt en je hebt nooit gespeeld met de kernel of zijn modules ( en dus geruineerd ;-), is nfs automagisch verkrijgbaar.
Je kan nu, op een root prompt, een geschikt commando intypen
en het file systeem zal te voorschijn komen. Doorgaand met het voorbeeld
in de vorige sectie willen we /mn/eris/local
moeten van eris.
Dat wordt gedaan met het commando:
mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt
(We komen terug op de rsize en wsize opties.) Het file systeem is
nu verkrijgbaar onder /mnt
en je kan daar naar cd
en,
en dan ls
er in doen, en dan kijken naar de individuele files.
Je zal merken dat het niet zo snel is als het lokale file systeem,
maar meer makkelijker dan ftp. Als in plaats van het file systeem mounten
mount zegt mount: eris:/mn/eris/local failed, reason given
by server: Permission denied
. Dan is de exports file fout, of
je bent exportfs vergeten draaiten nadat je de exports file hebt
geedit. Als het zegt mount clntudp_create: RPC: Program not registered
betekend dat dat mountd en nfsd niet op de server draaien.
Of je hebt het hosts.{allow,deny}
probleem wat eerder is aangegeven.
Om van het filesysteem af te komen kun je het volgende doen:
umount /mnt
Om een nfs file systeem bij het booten te mounten moet je je
/etc/fstab
file aanpassen op de normale manier. Bijvoorbeeld een regel
als deze is nodig:
# device mountpoint fs-type options dump fsckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0 ...
Dat is alles wat er is, bijna alles. Lees verder.
Er zijn enkele opties die je misschien gelijk moet toevoegen. Ze bestuur de manier hoe een NFS client op een server crash of netwerk uitval reageert. Een van de coole dingen van NFS is dat NFS hier goed mee overweg kan. Als je de clients goed instelt. Er zijn twee duidelijke faal modes:
De NFS client geeft een error aan het proces dat de file op het NFS gemounte file systeem gebruikt. Sommige programma's hanteren dit goed , de meeste niet. Ik kan deze setting niet aanbevelen, het is een recept voor slechte data en verloren data. Je moet dit zeker niet gebruiken voor mail disks ---- als je mail waarde heeft.
Het programma dat een file op een NFS gemount file systeem gebruikt
zal hangen als de server crasht. Het process kan niet gekilld of
geinterupt worden tenzij je intr
specificeerd. Als de NFS server
terug is zal het programma verder gaan waar het is gebleven. Ik
beveel aan hard,intr
te gebruiken op alle NFS gemounte file systemen.
Het vorige voorbeeld oppikken, dit is nu je fstab regel:
# device mountpoint fs-type options dump fsckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0 ...
Normaal, als er geen rsize en wsize opties zijn gespecificeerd zal NFS lezen en schrijven met stukken van 4096 of 8192 byte. Sommige combinaties van Linux kernels en netwerk kaarten kunnen zulke grote blokken niet aan, en het hoeft niet optimaal te zijn. Dus we willen expirimenteren en een rsize en wsize vinden die werkt en zo snel mogelijk is. Je kan de snelheid van je opties testen met enkele simpele commando's. Geef het mount commando hierboven en kijk of je schrijf rechten hebt en doe deze test om de opeenvolgende schrijf snelheid te meten:
time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096
Dit maakt een file van 64MB met nul bytes (welke groot genoeg moet zijn zodat cashing niet een veel betekenend gedeelte is van de gemerkte snelheid, gebruik een grotere file als je veel geheugen hebt). Doe het een paar (5-10?) keer en kijk naar de gemiddelde tijd. Het is de 'elapsed' of 'wall clock' tijd die het meest interessant is in deze connectie. Dan kun je de lees snelheid meten door de file terug te lezen:
time dd if=/mnt/testfile of=/dev/null bs=16k
doe dat een paar keer en kijk naar het gemiddelde. Dan unmounten en opnieuw mounten met een grotere rsize en wsize. Dat moeten vemigvuldigingen van 1024 zijn, en niet groter dan 16384 byte sinds dat de maximale groote in NFS versie 2 is. Direct na het mounten met een grotere grote cd in het gemounte file systeem en doe dingen als ls, verken het fs een beetje ik kijk of alles is zoals het hoort. Als de rsize/wsize te groot is zijn de symptonen erg vreemd en niet 100% duidelijk. Een typisch symtoon is een incomplete file lijst als je 'ls' doet, en geen error bericht. Of files lezen faalt mysterieus zonder error bericht. Na het testen of de gegeven rsize/wsize werkt kun je de snelheids test opnieuw doen. Verschillende server platforms hebben waarschijnlijk een verschillende optimale grootte. SunOS en Solaris zijn naar men zegt veel sneller met blokken van 4096 byte dan met alle andere mogelijkheden.
Nieuwere Linux kernels (sinds 1.3) doen vooruitlezen voor rsizes hoger of gelijk aan de machine page grootte. Op Intel CPUs is de page grootte 4096 byte. Vooruit lezen zal veel betekenend cd NFS lees snelheid opvoeren. Dus op een Intel machine wil je 4096 byte rsize als dat mogelijk is.
Onthoud dat je de /etc/fstab
update om de rsize/wsize in
te vullen die je hebt gevonden.
Een truuk om de NFS schrijf snelheid te verhogen is door gelijktijdig schrijven op de server uit te zetten. De NFS specificatie verklaart dat NFS schrijf vragen niet beschouwd als af als de data die is geschreven op een niet veranderlijk medium (normaal de disk). Dit beperkt de schrijf snelheid een beetje, asynchroon schrijven zal NFS schrijven versnellen. De Linux nfsd heeft nooit gelijktijdig schrijven gedaan omdat de Linux file systeem implementatie dat niet toestaat, maar op niet linux servers kun je de snelheid vergroten op deze manier met dit in je exports file:
/dir -async,access=linuxbox
of zoiets dergelijks. Zie de exports man page op besproken machine. Onthoud dat dit het risico van data verlies verhoogd.