linux user group brescia

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 ? : 
dovrebbe gestire meglio congestioni, perdita di pacchetti (su reti 
packet - lossy ) differenze di velocita'etc etc. Stesso risultato: 
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.

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".

[root a filesrv root]# umount -f /export/users
umount2: Device or resource busy
umount: /dev/sdd1: not mounted
umount: /export/users: Illegal seek

[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 :-)

Non e' che qualcuno vuole venire a provare 'sto coso? Offro una cena:-)


Alfredo Quartini wrote:
> 
> Ciao,
> 
> sto ancora "giocando" con la mia famigerata machina filesrv (ormai penso 
> di essere quasi una barzelletta:-) e, abbandonato (per ora;-) XFS sono 
> passato a ext3 e ext2. La macchina di per se funziona, nel senso che se 
> la metto soto stress "in locale" non da nessun problema.
> La questione è:
> 
> * exporto via NFS i filesystems che devono essere condivisi
> * monto sui client *** SOLO SUN Solaris 5.7/8/9 *** detti filesystems 
> via NFS
> 
> comincio a far frullare i dischi remoti e, dopo un po', ottengo sulla 
> console della macchina linux (che è il filesrv-nfs):
> 
> nfsd: last server has exited
> nfsd: unexporting all filesystems
> 
> e, a questo punto:
> 
> Linux permette di fare login, uno o due ls e poi... freeze. Unica 
> soluzione : spegnere la macchina.
> I client Solaris..... beh', vi lascio immaginare cosa succede, 
> soprattutto quando una delle risorse viene mappata tramite NIS (a dir la 
> verita' tutte le risorse esportate vengono acquisite dai client tramite 
> NIS).
> 
> Alcuni particolari:
> 
> Il filesrv monta una redHat 7.3, con i dovuti patch, kernel 2.4.20 
> compilato "ad hoc".
> Il numero di demoni fatti partire da '/etc/init.d/nfs start' è 16.
> 
> rpcinfo -p su detta macchina:
> 
>  program vers proto   port
>     100000    2   tcp    111  portmapper
>     100000    2   udp    111  portmapper
>     100007    2   udp    912  ypbind
>     100007    1   udp    912  ypbind
>     100007    2   tcp    915  ypbind
>     100007    1   tcp    915  ypbind
>     100011    1   udp    712  rquotad
>     100011    2   udp    712  rquotad
>     100011    1   tcp    715  rquotad
>     100011    2   tcp    715  rquotad
>     100005    1   udp  32768  mountd
>     100005    1   tcp  32781  mountd
>     100005    2   udp  32768  mountd
>     100005    2   tcp  32781  mountd
>     100005    3   udp  32768  mountd
>     100005    3   tcp  32781  mountd
>     100003    2   udp   2049  nfs
>     100003    3   udp   2049  nfs
>     100021    1   udp  32770  nlockmgr
>     100021    3   udp  32770  nlockmgr
>     100021    4   udp  32770  nlockmgr
>     100024    1   udp  32771  status
>     100024    1   tcp  32782  status
> 
> come si vede, è abilitato il supporto sia per le versioni NFS v2 che v3.
> I filesystem vengono esportati con :
> 
> /export/software 10.10.40.0/24(ro,sync)
> /export/users 10.10.40.0/24(rw,sync)
> /export/projects 10.10.40.0/24(rw,sync)
> /export/scratch 10.10.40.0/24(rw,sync)
> 
> usando l'opzione sync, come riportato da NFS-HowTo, per questioni di 
> compatibilità con NFS-Sun (dovrebbe essere il comportamento di default, 
> tra l'altro).
> Non è attivato il supporto per NFS over TCP ma mi aspetto che debba 
> funzionare lo stesso visto che questa feature la stanno includendo 
> adesso nella distribuzione del kernel.
> 
> qualche idea/suggerimento ?
> 
> Alfredo.
> 
> P.S: adesso sto andando con il kernel distribuito da redhat, il 2.4.18-3 
>  ricompilato (ma perche' non mettono PROBE ALL LUNS di defaults ?) e, al 
> momento in cui scrivo, non si e' ancora inchiodato....
>