linux user group brescia

Grazie per i suggerimenti,

NFS su TCP è supportato dalla versione di kernel 2.4.20.

Quello che si inchioda (non so poi come faccia a tirarsi dietro tutto il 
kernel) è proprio nfsd. I processi sono li... ma non rispondono piu'. Se 
provo a killarli '/etc/init.d/nfs stop' si ferma tutto. Uno 'showmount 
-e filesrv' non genera nessun risultato...

Per quanto riguarda la RAM, provero' a controllare, anche se "spero" non 
  ci siano problemi in quanto è appena arrivata nuova, ed e' di tipo ECC .

Pensi che la natura del filesystem esportato via NFS possa influire ? In 
questo momento sto cercando di stressare un ext2 / nfs (non si e' ancora 
bloccato ;-), mentre prima operavo su un ext3 / nfs.

Leggendo oltre  nel NFS-Howto, sono andato a verificare alcuni parametri 
  di basso livello nel kernel Linux / Solaris.

Solaris vorrebbe usare un rsize e wsize di 32K, mentre Linux opera, al 
piu', con chunk di 8K; a meno di ricompilare il kernel andando a 
cambiare la costante in .../kernel-dir/include/nfsd/const.h. Ma non so 
se è una buona idea..... ( a parte che non ho, quasi, nulla da perdere).

Inoltre, un altro  parametro sembra importante, cioe' la dimensione 
massima del buffer socket input queue, che di default e' 64k. Se, 
diciamo, faccio partire 16 demoni nfsd, ognuno avra' (al massimo) 4k 
disponibili e (magari!!!) sotto condizioni di forte carico qualcosa si 
perde e poi succede il disastro. La macchina è in grado di fare cose 
pesanti (DELL PowerEdge 1650, Dual PIII x 1.2GHz, interfaccia di rete 
Intel e1000, 2.5G memoria ECC).

Cosa ne dici?  Mi sembrerebbe una spiegazione plausibile per i messaggi 
  che talvolta compaiono sulle console dei client quando fanno frullare 
il server a mille:

NFS server not responding...
Still trying...

e poi, forse, riprendono come se nulla fosse successo.

Nell'HowTo c'e' scritto che sarebbe bene portare a 256K la dimensione 
del buffer ('echo 262144  > /proc/sys/net/core/rmem_max', per conto mio 
lo metterei anche ad un mega :-), ma il paragrafo termina con :

.... machines have been reported to crash if these values are left 
changed for long periods of time....

che non fa ben sperare.

Per quanto riguarda l'ozione 'soft' all'atto del mount, devo ancora 
scoprire come si passano eventuali parametri quando glihost acquisiscono 
i mount point tramite NIS.

Grazie,

Alfredo.



Luca Giuzzi wrote:
> On Sat, Feb 15, 2003 at 11:24:47AM +0100, Alfredo Quartini wrote:
> 
>>Ok,
>>
>>anche con il kernel 2.4.18-3 ci hanno dei problemi; pero', almeno, non 
>>si inchioda tutta la macchina come accade con il kernel 2.4.20. Ho 
>>provato anche a compilare il kernel con il supporto NFS-over-TCP. 
>>Sapevate che Solaris usa TCP come protocollo di trasporto per NFS ? : 
> 
> 
> Si'... NFS puo' essere usato sia sotto TCP che sotto UDP (pure sotto
> linux, ma non sono sicuro che le patches siano in un kernel 2.4 standard)
> 
> 
>>dovrebbe gestire meglio congestioni, perdita di pacchetti (su reti 
>>packet - lossy ) differenze di velocita'etc etc. Stesso risultato: 
> 
> 
> Il problema nell'uso di TCP e' che in questo caso si perde la natura
> "connectionless" di NFS che e' uno dei suoi punti di forza... chiaro:
> nono si puo' avere tutto dalla vita :)
> 
> 
>>macchina bloccata la mattina quando arrivo dopo che, di notte, avevo 
>>lasciato in loop un paio di client che eseguo "bonnie", un paio che 
>>fanno "ls -lR" ricorsivamente, ed un altro che compila su un filesystem 
>>montato via nfs.
>>
> 
> Controlla la RAM... che c'e' nei files di log? In caso estremo: puoi
> collegare un altro computer alla macchina che si e' bloccata via 
> seriale e reindirizzare li' la console?
> 
> 
>>Curiosita':
>>
>>[root a filesrv root]# uname -a
>>Linux filesrv 2.4.18-3custom #1 SMP Mon Feb 3 19:33:32 CET 2003 i686 unknown
>>
>>[root a filesrv root]# mount
>>/dev/sda5 on / type ext2 (rw)
>>none on /proc type proc (rw)
>>usbdevfs on /proc/bus/usb type usbdevfs (rw)
>>/dev/sda2 on /boot type ext2 (rw)
>>none on /dev/pts type devpts (rw,gid=5,mode=620)
>>/dev/sda9 on /home type ext2 (rw)
>>none on /dev/shm type tmpfs (rw)
>>/dev/sda8 on /tmp type ext2 (rw)
>>/dev/sda7 on /usr type ext2 (rw)
>>/dev/sda6 on /var type ext2 (rw)
>>/dev/sdc1 on /export/software type ext2 (rw)
>>/dev/sdd1 on /export/users type ext3 (rw)
>>/dev/sde1 on /export/projects type ext3 (rw)
>>/dev/sdf1 on /export/scratch type ext3 (rw)
>>
>>[root a filesrv root]# umount /export/users
>>umount: /export/users: device is busy
>>
> 
> 
>>Qui è un po' difficile riusciere a capire perche' e' busy il filesystem 
>>/export/users. Non e' nemmeno accessibile, non ci si puo' neppure 'ls'. 
>>Provo a smontarlo "di forza".
> 
> 
> prova con fuser su quel filesystem... probabilmente e' bloccato da uno
> zombie.
> \
> 
>>[root a filesrv root]# umount -f /export/users
>>umount2: Device or resource busy
>>umount: /dev/sdd1: not mounted
>>umount: /export/users: Illegal seek
>>
> 
> umount -f non e' supportato dai kernels 2.4, sorry...
> Illegal seek suggerirebbe o problemi a livello di partizione/hd o
> problemi di ram... fai una verifica con memtest...
>  
> 
>>[root a filesrv root]# cat /etc/mtab
>>/dev/sda5 / ext2 rw 0 0
>>none /proc proc rw 0 0
>>usbdevfs /proc/bus/usb usbdevfs rw 0 0
>>/dev/sda2 /boot ext2 rw 0 0
>>none /dev/pts devpts rw,gid=5,mode=620 0 0
>>/dev/sda9 /home ext2 rw 0 0
>>none /dev/shm tmpfs rw 0 0
>>/dev/sda8 /tmp ext2 rw 0 0
>>/dev/sda7 /usr ext2 rw 0 0
>>/dev/sda6 /var ext2 rw 0 0
>>/dev/sdc1 /export/software ext2 rw 0 0
>>/dev/sdd1 /export/users ext3 rw 0 0
>>/dev/sde1 /export/projects ext3 rw 0 0
>>/dev/sdf1 /export/scratch ext3 rw 0 0
>>
>>Almeno si inchiodasse solo il server. quando lui comincia a dare i 
>>numeri, pure i client Solaris vanno fuori di matto :-)
> 
> 
> Normale :((
> NFS e' connectionless.. le macchine provano ad accedere al filesystem
> e poi si fermano aspettando una risposta (prova a montare gli shares
> con l'opzione soft)
> 
> ciao,
>  lg
>