Først trenger du en kernel med NFS filsystem enten kompilert inn eller tilgjengelig som en modul. Dette konfigureres før du kompilerer kernelen. Hvis du aldri har kompilert en kernel før må du kanskje sjekke kernel HOWTO og finne ut av det. Hvis du bruker en ganske god distribusjon (som Red Hat) og du aldri har fiklet med kernelen eller modulene til den (og dermed ødelagt den ;-), er nfs sansynligvis allerede tilgjengelig for deg.
Du kan nå, ved root prompten, skrive en passende mount kommando
og filsystemet vil dukke opp. For å fortsette på eksempelet i
forrige del ønsker vi nå å mounte /mn/eris/local fra eris. Dette
gjøres med denne kommandoen:
mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt
Vi kommer tilbake til rsize og wsize valgene.) Filsystemet er nå
tilgjengelig under /mnt og du kan cd dit, og ls i det, og se på de
forskjellige filene. Du vil legge merke til at det ikke er fullt så
raskt som et lokalt filsystem, men mye mer praktisk enn ftp. Dersom,
istedet for å mounte filsystemet, mount gir en feil melding som
mount: eris:/mn/eris/local failed, reason given by server: Permission denied da er det noe galt i exports fila, eller du har
glemt å kjøre exportfs etter å ha editert exports fila. Hvis det
sier mount clntudp_create: RPC: Program not registered betyr det at
nfsd eller mountd ikke kjører på serveren.
For å fjerne filsystemet igjen kan du skrive
umount /mnt
For å få systemet til å mounte et nfs filsystem ved oppstart editerer
du /etc/fstab på vanlig måte. For vårt eksempel trengs en linje som
dette:
# device mountpoint fs-type options dump fsckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0 ...
Det er alt som trengs, omtrent. Les videre er du grei.
Det er noen valg du bør vurdere å bruke med en gang. De styrer måten NFS klienten takler en server kræsj eller nettverk mangel/trøbbel. En av de gode sidene til NFS er at det kan takle dette glatt. Dersom du setter opp klienten riktig. Det er to distinkte feil moduser:
NFS klienten vil rapportere og feile prosessen som prøver å nå en fil på et NFS montert filsystem. Noen programmer takler dette på en grei måte, det fleste ikke. Jeg kan ikke anbefale dette valget.
Programmet som prøver å få adgang til en fil på et NFS montert
filsystem vil henge når serveren kræsjer. Prosessen kan ikke bli
forstyrret eller drept uten at du også spesifiserer intr. Når
NFS serveren er tilbake på nettet vil programmet fortsette
uforstyrret fra der det slapp. Dette er sansynligvis det du
ønsker. Jeg anbefaler å bruker hard,intr på alle NFS monterte
filsystemer.
Fortsetter på forrige eksempelet, og dette er nå linjen i fstab:
# device mountpoint fs-type options dump fsckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0 ...
Vanligvis, dersom ingen rsize og wsize valg er satt vil NFS lese og skrive i blokker på 4096 eller 8192 bytes. Noen kombinasjoner av Linux kerneler og nettverkskort takler ikke så store blokker, og det er kanskje ikke optimalt heller. Så vi vil eksperimentere og finne en rsize og wsize som virker og er så rask som mulig. Du kan teste farta på dine valg med noen enkle kommandoer. Gitt mount kommandoen over og du har skrive adgang til disken så kan du teste den sekvensielle skrive ytelsen:
time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096
Dette lager en 64Kb file med null bytes (som skulle være stort nok til at caching ikke er noen signifikant del av ytelsen, bruk en større fil dersom du har mye minne). Gjør dette noen ganger (5-10?) og finn den gjennomsnittlige tiden. Det er `elapsed' eller `wall clock' tid som er mest interessant i denne forbindelse. Da kan du teste lese ytelsen ved å lese filen:
time dd if=/mnt/testfile of=/dev/null bs=16k
Gjør dette noen ganger og finn gjennomsnittet. Så umount, og mount igjen med en større rsize og wsize. De bør kanskje være multipler av 1024, og ikke større enn 16384 bytes siden det er maksimum størrelse i NFS versjon 2. Rett etter mount med en større størrelse cd inn i det mountede filsystemet og gjør ting som ls, utforsk filsystemet litt for å være sikker på at alt er som det skal. Hvis rsize/wsize er for stor er symptomene veldig rare og ikke 100% åpenbare. En typisk symptom er ukomplette fillister når du bruker ls, og ingen feilmeldinger. Eller lesing av filer feiler på merkelige måter uten feilmeldinger. Etter å ha fastslått at gitte rsize/wsize virker kan du kjøre ytelsestestene igjen. Forskjellige server plattformer har ofte forskjellige optimale størrelser. SunOS og Solaris er ofte mye raskere med 4096 byte blokker enn noe annet.
Nyere Linux kerneler (siden 1.3 en gang) bruker forhåndslesing for rsize større eller lik maskinens page size. På Intel CPUer er page size 4096 bytes. Forhåndslesing vil øke NFS lesing signifikant. Så på en Intel maskin vil du bruke 4096 byte rsize dersom det er mulig.
Husk å editere /etc/fstab med de nye rsize og wsize.
Et triks for å øke NFS skrive ytelse er å slå av synkron skriving på serveren. NFS spesifikasjonen sier at NFS skrive ønsker ikke skal oppfattes som ferdige før dataene som er skrevet er på et ikke- "flyktig" (non-volatile) medium (vanligvis harddisken). Dette begrenser skrive-ytelsen noe, asynkrone skrivinger vil øke NFS skrivefarten. Linux nfsd har aldri foretatt synkrone skrivinger siden Linux filsystem implementasjonen ikke tillater dette, men på ikke-Linux servere kan du øke ytelsen på denne måten med dette i exports fila:
/dir -async,access=linuxbox
eller noe lignende. Les exports man sidene på maskinen det gjelder. Merk at dette øker risikoen for tap av data.