Ho ancora per le mani un paio di server Silicon Graphics Origin 200 (roba del 2000, che va ancora senza il minimo problema).
Nell’impianto dove sono impiegati, questi due server montano via NFS uno spazio disco condiviso da un server SUNFire 6800.
Arrivato il momento della pensione per il SunFire (le macchine SGI ci andranno a fine anno), è stato sostituito da un server DL380 di HP, con 5Tb di disco, con installato CentOS.
A metà della procedura di sostituzione, controllando che i servizi che girano sul Origin 200 operassero regolarmente, è saltato fuori un problema veramente curioso. Supponiamo che la macchina CentOS esporti una directory chiamata alfa, con dentro due directory beta e gamma. La macchina SGI avrà nel file /etc/fstab una riga tipo questa:
centos:/alfa /puntodimount nfs defaults 0 0
Fin qui nulla di strano. L’anomalia salta fuori se si entra nella directory /puntodimount, e di usa il comando pwd:
# cd /puntodimount
# pwd
/
#
la risposta dovrebbe essere invece /puntodimount, ossia viene “eliminato” percorso di mount dalla directory corrente. Naturalmente in questo frangente tutti i servizi che controllano dove si trovano prima di operare non funzionano più, perché se vogliono andare dentro /puntodimount/beta, al controllo di “dove sono” (pwd), si vedono dentro /beta.
Dopo un paio di passaggi con Google ne sono venuto a capo: è un bug noto di IRIX 6.5.12 e precedenti, il numero 815265, la cui criptica definizione è: IRIX not liking file handles of less than 32 bytes. Il bug è risolto nella versione 6.5.13, ma, naturalmente, non è possibile fare alcun aggiornamento della macchina IRIX, meno che mai un aggiornamento di sistema operativo, che porterebbe ben altri problemi.
La soluzione è di usare l’opzione vers=2 nel file /etc/fstab del client IRIX, in questo modo:
centos:/alfa /puntodimount nfs defaults,vers=2 0 0
Risolto questo problema, naturalmente, è uscito fuori quello che stava sotto, più grande: le prestazioni pietose. Per capirci, creando un file da 100M dalla macchina SGI sul server NFS Linux, questo è stato il risultato:
# time dd if=/dev/zero of=/LGCACHE/provamario bs=1024000 count=100
100+0 records in
100+0 records out
0.0u 2.0s 5:56 0% 0+0k 3+6250io 0pf+0w
Tradotto, 5 minuti e 56 secondi per creare il file, ossia 280kb/sec, roba che neanche con una rete a 10 mbit.
Facendo il solito giro, stavolta sui newsgroup, ho trovato un paio di messaggi che spiegano perché e come risolvere. In breve: mentre l’implementazione di SUN del server NFS lavora bene con l’impostazione synchronous writes, ossia il server risponde “ho scritto” ad ogni richiesta solo dopo che ha effettivamente scritto sul disco i dati, lasciando in attesa il client, l’implementazione in Linux lavora meglio con l’impostazione asynchronous writes, dove il server risponde immediatamente “ho scritto” alla corretta ricezione dei dati. L’effetto è che le scritture su disco, in Linux, vengono accumulate ed eseguite a gruppi, eliminando di fatto l’attesa per il client.
Aggiungendo nel server Linux alla riga di definizione della share NFS nel file /etc/exports il parametro async si ottiene questo risultato, con lo stesso test di scrittura:
# time dd if=/dev/zero of=/LGCACHE/provamario1 bs=1024000 count=100
100+0 records in
100+0 records out
0.0u 1.7s 0:11 15% 0+0k 1+6255io 0pf+0w
solo 11 secondi, pari a 9,3Mb/sec, un risultato ben diverso da prima.
Riferimenti
- Il Linux NFS HOWTO, al paragrafo 8.5.2, dove nomina questo problema specifico, ma tutti i link riportati sono “rotti”, quindi non forniscono soluzioni
- Linux NFS FAQ su Sourceforge, al punto E3 riporta la soluzione.
- Il messaggio nel newsgroup comp.protocols.nfs che spiega il perché delle lentezze della accoppiata Linux/SGI con NFS
- Il messaggio nel newsgroup comp.os.linux.development.system che mostra un test di confronto su server NFS Linux con e senza l’opzione async
