Nfs-kernel-server: possibili problemi e prestazioni

NFS

Sommario

Spazio Kernel Principale NFS V2-V3 NFS V4 Lato server Lato client Diagnostica e prestazioni Approfondimenti Client Windows Esempi

Troubleshooting

Inconveniente 1

Tra i problemi tipici c'è quello di non riuscire a montare le risorse remote. Una prima verifica banale è quella di assicurarsi che la cartella dove devono essere montate le risorse remote sia indicata correttamente (per esempio /home/nfs è DIVERSO da /home/NFS). Una seconda causa potrebbe essere dovuta al numero della porta che NFS sceglie casualmente, infatti se il numero della porta è maggiore di 1024 scatta un errore di sicurezza; in tal caso è sufficiente aggiungere alle opzioni indicate nel file /etc/exports anche insecure, ad esempio:

/home       192.168.1.0/24(rw,fsid=0,no_subtree_check,sync,insecure)
/home/altro 192.168.1.0/24(rw,no_subtree_check,sync,insecure)

Un altro motivo potrebbe essere costituito dal set di permessi delle cartelle esportate; provare ad impostare temporaneamente i loro permessi su 777. Se il problema è risolto provare a reimpostare i permessi sul vecchio schema e vedere se l'errore si ripropone.

Inconveniente 2

Nel caso il server sia spento e sulla macchina client sia presente un collegamento simbolico alle risorse esterne, creato per esempio con un comando del tipo:

# ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario

è probabile che si noti un ritardo di circa 2 minuti all'avvio di gnome (nel caso di caricamento automatico all'avvio) ed ogni volta che si lancia nautilus per visualizzare una qualche cartella. La semplice presenza del collegamento simbolico è infatti sufficiente ad innescare una richiesta di caricamento per le risorse remote, con la conseguenza che essendo il server spento queste falliscano inevitabilmente. Di base nfs è impostato per ripetere la richiesta di caricamento risorse dopo 2 minuti, ecco dunque da dove nascerebbero il ritardo sistematico. In tal caso la soluzione più semplice è rinunciare ai collegamenti simbolici verso le risorse remote caricate tramite nfs, altrimenti è possibile ridurre tale ritardo specificando nelle opzioni di mount (o di fstab o di auto.nfs, ecc.) retry=X, dove X è il nuovo numero di minuti (si noti che l'opzione retrans è utile solo nel caso si usi l'opzione soft e non hard). Può anche capitare che uno o più processi legati a nfs rimangano in sospeso nonostante il server sia normalmente funzionante; in tal caso se si sono specificate le opzioni hard,intr dovrebbe essere possibile uccidere i relativi processi con kill -9 pid, in caso contrario è probabile che non ci sia altra soluzione che riavviare brutalmente la macchina client. Altre problematiche sono descritte al punto 7 di questa pagina.

Inconveniente 3

Potrebbe capitare che trasferendo grossi file il server si congeli obbligando ad un riavvio forzato, in tal caso potrebbe essere utile specificare sulla macchina client le opzioni rsize (influenza le operazioni di scrittura sulla macchina client) e wsize (influenza le operazioni di scrittura sulla macchina server) indicando valori non troppo grandi, per esempio:

• Caso statico: mount -t nfs4 -o _netdev,rsize=4096,wsize=4096,hard,intr indirizzo_server:/ /home/NFS

• Caso statico, file /etc/fstab aggiungere (o modificare quella già esistente): indirizzo_server:/ /home/NFS nfs4 _netdev,auto,rsize=4096,wsize=4096,hard,intr 0 0

• Caso dinamico, file /etc/auto.nfs aggiungere (o modificare quella già esistente) nome_arbitrario -fstype=nfs4,_netdev,rsize=4096,wsize=4096,hard,intr indirizzo_server:/

A tal proposito potrebbe essere utile leggere questo.

Inconveniente 4

Potrebbe anche capitare nel caso di NFSv4 che la macchina client veda crollare drasticamente a poche centinaia di kb/s la velocità di trasferimento dati quando si va a scrivere sulla macchina server grossi file. In tal caso controllare in primis di usare l'opzione crossmnt invece di nohide (si riveda la sezione dedicata al rimontaggio delle cartelle), se anche questo non funziona provare ad aggiungere nel file exports le opzioni async e no_wdelay ad ogni cartella da esportare. Un'altra possibilità è provare ad usare il protocollo UDP invece di TCP, si tratta di aggiungere l'opzione proto=UDP al comando mount (trattasi cioè di un opzione lato client). Se anche questo non dovesse funzionare provare a guardare questa pagina (si tratta di ricompilare il kernel, sempre che poi sia proprio questo il problema).

Prestazioni

È possibile migliorare le prestazioni affinando i valori dei vari parametri, ed è argomento tutt'altro che ridotto, come dimostrato qui e qui.
I primi parametri da controllare sono tuttavia rsize e wsize, che di base valgono 8192 per NFSv2-NFSv3 e 32768 per NFSv4. Stando al manuale tali valori devono essere multipli interi di 1024 e compresi tra un minimo di 4096 byte e 1048576 byte.

Esempio 1

• Cavo rete sstp cat.6, L = 50 m;
• Server: Debian Wheezy, AMD Sempron 145 2,8 GHz, scheda di rete GBit integrata, HD 2,5" sata II 5400 rpm ext4, DDr2 2 GB 667 Mhz ram;
• Client: Debian Wheezy, Intel Core Duo 2 3 GHz, scheda di rete GBit integrata, HD 3,5" sata II 5400-7200 rpm (caviar green) ext4, DDr2 3 GB 1066 Mhz ram;
• File trasferito: video '.mkv' da 8 GB.
  
• NFSv4: rsize=wsize=65536,sync,TCP,no_subtree_check,hard,intr;
  • Velocità media trasferimento Server --> Client: 49,8 MB/s circa
  • Velocità media trasferimento Client --> Server: 72,8 MB/s circa
    
• SFTP;
  • Velocità media trasferimento Server --> Client: 22,8 MB/s circa
  • Velocità media trasferimento Client --> Server: 26,3 MB/s circa

Esempio 2

• Come esempio 1 salvo ove diversamente specificato;
• Server: Debian Squeeze, AMD Athlon (slot A) 650 MHz, scheda di rete GBit PCI, HD 3,5" ATA100 5400 rpm ext4 lvm2, DIMM 364 MB ram 100 Hz;
  
• NFSv4: rsize=wsize=8192,sync,TCP,no_subtree_check,hard,intr;
  • Velocità media trasferimento: 15 MB/s circa
    
• SFTP;
  • Velocità media trasferimento: 5,5 MB/s circa