Nfs-kernel-server: condividere risorse tra macchine GNU/Linux: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Nfs-kernel-server: condividere risorse tra macchine GNU/Linux (visualizza wikitesto)

Versione delle 11:29, 11 ago 2011

Nessun cambiamento nella dimensione ,  11 ago 2011
m
Annullata la modifica 26273 di Wtf (discussione)
m (Annullata la modifica 26273 di Wtf (discussione))
Riga 295: Riga 295:


==== Inconveniente 2 ====
==== 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:
<pre># ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario</pre>
è 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.) <code>retry=X</code>, dove X è il nuovo numero di minuti (si noti che l'opzione <code>retrans</code> è 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 <code>hard,intr</code> dovrebbe essere possibile uccidere i relativi processi con <code>kill -9 pid</code>, in caso contrario è probabile che non ci sia altra soluzione che riavviare brutalmente la macchina client.
Altre problematiche sono descritte al punto 7 di [http://nfs.sourceforge.net/nfs-howto/ 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:
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:
Riga 305: Riga 315:


A tal proposito potrebbe essere utile leggere [http://nfs.sourceforge.net/nfs-howto/ar01s07.html#cpu_cycles_nfs questo].
A tal proposito potrebbe essere utile leggere [http://nfs.sourceforge.net/nfs-howto/ar01s07.html#cpu_cycles_nfs questo].
==== Inconveniente 3 ====
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:
<pre># ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario</pre>
è 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.) <code>retry=X</code>, dove X è il nuovo numero di minuti (si noti che l'opzione <code>retrans</code> è 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 <code>hard,intr</code> dovrebbe essere possibile uccidere i relativi processi con <code>kill -9 pid</code>, in caso contrario è probabile che non ci sia altra soluzione che riavviare brutalmente la macchina client.
Altre problematiche sono descritte al punto 7 di [http://nfs.sourceforge.net/nfs-howto/ questa pagina].


==== Inconveniente 4 ====
==== Inconveniente 4 ====
Wtf
3 155

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/26274"

Menu di navigazione