Prima di tutto avete bisogno di un kernel che abbia il supporto
per NFS compilato staticamente oppure come modulo. Questo lo si configura
prima di iniziare la compilazione. Se non avete mai compilato un kernel
prima, leggete il Kernel HOWTO. Se state usando una buona distribuzione
(come Red Hat [meglio Debian N.d.T]) e non avete mai
messo mano al kernel o ai moduli (rovinandolo ;)), allora nfs dovrebbe
essere già disponibile.
Ora, dal prompt di root, potete lanciare il comando appropriato e
vedere il file system apparire. Continuando l'esempio della sezione
precedente, vogliamo montare la partizione in /mn/eris/local
da eris. Ciò è fatto con il comando:
mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt
(Torneremo successivamente sulle opzioni rsize e wsize). Il file
system è ora disponibile sotto
/mnt, potete fare
cd in esso
e con un
ls vedere tutti i file che vi sono presenti. Noterete
che non è così veloce come su un file system locale, ma molto più
conveniente che usare ftp. Se, invece di montare il file system, il
comando mount produce un errore come
mount: eris:/mn/eris/local
failed, reason given by server: Permission denied, significa che il file
exports è errato oppure avete dimenticato di lanciare il comando exportfs
dopo averlo modificato. Se invece dice
mount clntudp_create: RPC:
Program not registered significa che nfsd o mountd non sta
girando sul server oppure c'è un problema nel file
hosts.allow,deny
di cui abbiamo parlato precedentemente.
Per rimuovere il filesystem, usare il comando:
umount /mnt
Per fare in modo che il sistema monti un file system al boot,
occorre modificare il file
/etc/fstab. Per il nostro esempio
aggiungere la seguente riga:
# device mountpoint fs-type options dump fsckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0
...
Questo è tutto, più o meno.
Ci sono alcune opzioni che dovreste considerare almeno una volta.
Controllano il modo in cui i client NFS gestiscono i crash della rete
o del server. Uno dei fattori positivi di NFS è che questi problemi
vengono gestiti molto bene... se configurate i client in modo corretto.
Ci sono due tipi di problemi:
- soft
-
Riprendendo l'esempio precedente, modifichiamo la linea dell'fstab:
# device mountpoint fs-type options dump fsckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
...
Normalmente, se non vengono usate le opzioni rsize e wsize, NFS
leggerà e scriverà blocchi di 4096 o 8192 byte. Alcune combinazioni
di kernel di Linux e schede di rete possono non essere in grado di
gestire blocchi così grandi o potrebbero non esserlo comunque in maniera
ottimale. Quindi dobbiamo
provare a sperimentare varie dimensioni per determinare quali siano
i parametri che funzionano e garantiscono le migliori prestazioni.
Si può provare l'influenza delle opzioni sulla velocità con alcuni
semplici comandi. Se avete montato la partizione come visto precedentemente e avete
i diritti di scrittura, potete provare con il seguente test di scrittura
sequenziale:
time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096
In questo modo si crea un file di 64 MB di zeri (grande abbastanza per fare
in modo che l'uso della cache non sia significativo sulle prestazioni;
usate una dimensione maggiore se avete molta memoria disponibile).
Lanciatelo alcune volte (5-10?) e calolate il tempo medio. Il tempo
da tenere maggiormente in considerazione è quello indicato
con 'elapsed' oppure 'wall clock'. Potete quindi verificare le prestazioni in
lettura:
time dd if=/mnt/testfile of=/dev/null bs=16k
Fatelo alcune volte e calcolate la media dei tempi. Quindi smontate e rimontate
la partizione nuovamente ma con rsize e wsize maggiori. Dovrebbero
essere sempre multipli di 1024 e non essere più grandi di 16384, che
è la dimensione massima ammessa da NFS versione 2. Dopo averla
montata nuovamente, fate un cd nel file system montato e provate qualche
semplice comando tipo ls, esplorate il file system per verificare
se tutto funziona correttamente. I sintomi di rsize/wsize
troppo grandi, sono
molto strani e per nulla ovvi. Un sintomo
tipico è un elenco incompleto di file quando viene fatto un 'ls', senza
alcun messaggio di errore. Oppure la lettura dei file fallisce miseramente
senza messaggi di errore. Dopo avere stabilito che le dimensioni di
rsize e wsize funzionano, potete provare di nuovo a effettuare i controlli.
Server diversi hanno dimensioni ottimali diverse. SunOS e Solaris
hanno la reputazione di andare molto più veloci con blocchi di 4096 byte.
I kernel di Linux più recenti (dal 1.3), eseguono un read-ahead
per rsize di dimensioni maggiori o uguali alla dimensione della pagina
della macchina. Sui processori Intel, la dimensione della pagina è di
4096 byte. Poiché l'uso del read-ahead aumenta significativamente
le prestazioni in lettura di NFS, raccomando di impostare a 4096 le dimensioni
di rsize.
Ricordatevi di modificare /etc/fstab per riflettere le dimensioni
di rsize/wsize che avete trovato essere le migliori.
Un trucco per accelerare le prestazioni in scrittura di NFS è
quello di disabilitare la scrittura in sincronia sul server. Le
specifiche di NFS controllano che le richieste di scrittura sul server
non siano considerate terminate finché i dati non siano memorizzati su
un supporto non volatile (il disco). Questo limita le prestazioni
in scrittura, per cui disabilitando questa caratteristica si otterrà
un incremento delle prestazioni. Il nfsd di Linux non ha più fatto
scritture sincrone da quando non lo fa nemmeno il file system stesso.
Su macchine non Linux, è possibile migliorare le prestazioni modificando
in questo modo il file /etc/exports:
/dir -async,access=linuxbox
o in modo simile. Fate riferimento alla pagina man relativa
al file exports della macchina in questione. Da notare che ciò
aumenta la possibilità di perdita di dati.