linux user group brescia

immagine del castello

Archivio della mailing list

[LugBS] laboratorio che si impalla!

Andrea Gelmini andrea.gelmini a lugbs.linux.it
Ven 12 Mar 2010 21:22:13 UTC
Il 12 marzo 2010 19.00, ollenotna2000 <ollenotna2000 a yahoo.it> ha scritto:
> Davvero non saprei ricostruire l'inizio dei problemi. Ora, la questione
> dischi potrebbe avere un senso, trattandosi di macchinari un poco datati.
> Lanciare un fschk potrebbe tornare utile?
Oddio, dipende...
Con fsck hai solo un controllo dei metadata. Se il problema risiede
nei dati di un file (sia in lettura che in scrittura), in questo modo
non lo sai.
Pero' hai il vantaggio che tutti gli I/O error sono loggati.
Insomma, ti basta greppare sui log e sicuramente qualcosa fai saltare
fuori (se questo fosse il caso).

> Il server ha installato nfs-kernel-server (mi pare di aver capito che è
> preferito a nfs-common per questioni di velocità)
> In /etc/init.d/nfs-kernel-server ho aumentato
> RPCNFSDCOUNT=32
> per avere più istanze per accogliere i client (stupidata?)

Un paio di cose:
a) la distinzione è tra il servizio di NFS implementato nel server
(nfs-kernel-server) e quello in user space; di fatto non credo che
piu' nessuno, da tempo immemore, usi il secondo;
b) nfs-common è il pacchetto che contiene i servizi per il lock/ecc
via NFS. Si chiama common perchè in comune sia alla parte server che
quella client. Insomma, per usare nfs devi averlo installato sia sui
client che sui server;
c) a mio avviso il tuo problema non è dato da NFS (ma è solo una
sensazione, non ho elementi per dimostrarlo).

> mount -t nfs -o rw,rsize=8192,wsize=8192,hard,intr,timeo=14,nosuid
> 192.168.0.1:/home /home

Allora, non starei a impazzire ora con i parametri e soprattutto con
NFS che, ripeto, a mio avviso non sono l'origine del problema.
Detto questo, le cose che farei (in un secondo tempo) sarebbero queste:
a) forzerei l'utilizzo di TCP, in luogo di UDP (questo per evitare la
corruzione dei file in scrittura in alcuni scenari possibili di noie
sulla rete) (flag tcp);
b) abiliterei un po' di caching (flag ac);
c) valuterei l'ipotesi di non montare in modalita' hard, ma soft. Ma
questo è opinabile e nel caso se ne puo' discutere (flag soft);
d) puoi anche sbizzarrirti con i parametri di read/write size;

Insomma, sul mio server di casa monto in questa maniera:

gelma a vaio:/tmp$ grep nfs /etc/fstab
siae:/siae					/home/gelma/mnt/siae	nfs	defaults,tcp,ac,soft,rsize=1048576,wsize=1048576

Detto questo sono convinto che l'origine del problema stia da un'altra parte.

Se proprio vuoi sbizzarrirti (ma questo sempre per il poi, quando
avremo risolto) con le performance puoi pensare:
a) di utilizzare il nuovo sistema di nfs caching (ma richiedono kernel
molto recenti su tutte le macchine);
b) di provare file system di rete alternativi come POHMELFS, gia'
progettati in un'ottica di scalabilita'/performance spinte.

Se hai difficolta' a trovare il problema posso eventualmente fare un
salto nel tuo laboratorio, magari mentre i bambini stanno lavorando.
Non sono cose difficili da scovare, ma se non ti ci sei mai imbattuto
puoi perderci parecchio tempo, rispetto a chi ci ha gia' sbattuto il
naso.

Ciao,
gelma




Maggiori informazioni sulla lista Lug