linux user group brescia

Ieri ho lasciato un po' di processi che lavoravano via NFS e, questa 
mattina, ho trovato tutto inchiodato (come al solito :-) ma con una novita':

Feb 16 17:38:18 filesrv kernel: Assertion failure in 
journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)"
Feb 16 17:38:18 filesrv kernel: ------------[ cut here ]------------
Feb 16 17:38:18 filesrv kernel: kernel BUG at commit.c:535!
Feb 16 17:38:18 filesrv kernel: invalid operand: 0000
Feb 16 17:38:18 filesrv kernel: nfsd lockd sunrpc autofs e1000 ext3 jbd 
usb-ohci usbcore aic7xxx sd_mod scsi_m
Feb 16 17:38:18 filesrv kernel: CPU:    1
Feb 16 17:38:18 filesrv kernel: EIP:    0010:[<f88f40e4>]    Not tainted
Feb 16 17:38:18 filesrv kernel: EFLAGS: 00010286
Feb 16 17:38:18 filesrv kernel:
Feb 16 17:38:18 filesrv kernel: EIP is at journal_commit_transaction 
[jbd] 0xb04 (2.4.18-3custom)
Feb 16 17:38:18 filesrv kernel: eax: 0000001c   ebx: 0000000a   ecx: 
c02ee460   edx: 00003b9e
Feb 16 17:38:18 filesrv kernel: esi: ef18d250   edi: de485800   ebp: 
c9dd8000   esp: c9dd9e78
Feb 16 17:38:18 filesrv kernel: ds: 0018   es: 0018   ss: 0018
Feb 16 17:38:18 filesrv kernel: Process kjournald (pid: 7183, 
stackpage=c9dd9000)
Feb 16 17:38:18 filesrv kernel: Stack: f88fac2e 00000217 c890d040 
00000000 00000fd4 c7b1f02c 00000000 edadc5a0
Feb 16 17:38:18 filesrv kernel:        ef18d460 000019c4 f57c3300 
c03542c0 f7045000 f7045210 ea029300 cce44c80
Feb 16 17:38:18 filesrv kernel:        cce447a0 f70451e4 c9dd9ed4 
00000001 f57c3300 f57c3300 f7045000 c01dd41b
Feb 16 17:38:18 filesrv kernel: Call Trace: [<f88fac2e>] .rodata.str1.1 
[jbd] 0x26e
Feb 16 17:38:18 filesrv kernel: [<c01dd41b>] net_rx_action [kernel] 0x1eb
Feb 16 17:38:18 filesrv kernel: [<c01818a2>] add_interrupt_randomness 
[kernel] 0x22
Feb 16 17:38:18 filesrv kernel: [<c0120f3b>] do_softirq [kernel] 0x7b
Feb 16 17:38:18 filesrv kernel: [<c010a77f>] do_IRQ [kernel] 0xdf
Feb 16 17:38:18 filesrv kernel: [<c011a612>] .text.lock.sched [kernel] 0x78
Feb 16 17:38:18 filesrv kernel: [<f88f67d6>] kjournald [jbd] 0x136
Feb 16 17:38:18 filesrv kernel: [<f88f6680>] commit_timeout [jbd] 0x0
Feb 16 17:38:18 filesrv kernel: [<c0107286>] kernel_thread [kernel] 0x26
Feb 16 17:38:18 filesrv kernel: [<f88f66a0>] kjournald [jbd] 0x0
Feb 16 17:38:18 filesrv kernel:
Feb 16 17:38:18 filesrv kernel:
Feb 16 17:38:18 filesrv kernel: Code: 0f 0b 5a 59 6a 04 8b 44 24 18 50 
56 e8 4b f1 ff ff 8d 47 48
Feb 17 09:28:23 filesrv rpc.mountd: export request from 127.0.0.1



adesso sto cercando sulla rete se ci sono esperienze di incompatibilita' 
  server Linux NFS / EXT3 / Solaris.
In contemporanea, ho riformattato tutto in ext2 ed ho ricominciato a 
martellare.
Vedremo....


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
>