I am playing with an iSCSI device on FreeBSD client running UFS2 on the device over a LAN. Everything works well until I reboot the iSCSI server - the client pauses for a minute or so then continues working after iSCSI server comes back. No I/O errors are reported. Everything seems to work fine for a little while! But shortly afterwards, I get a panic with the message panic: ffs_valloc: dup alloc It seems related to the length of the delay the iSCSI device is paused - restarting the iSCSI target daemon process doesn't cause the problem but rebooting the whole target box does cause it. 1. Could this be related to the patch Matt Dillon created years ago which I found here? http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html 2. Can anyone think of any other reason this might happen? I know I am stretching UFS to the limits here, expecting it to pause and restart after more than a minute of locked disk :-) However, since all I/O eventually complete successfully and no errors are reported, I find it suspicious. Cheers - Andrew ps. running latest iSCSI code 2.1 on latest 7-STABLE box.
Alfred Perlstein
2008-Oct-05 07:56 UTC
trying to track down UFS "dup alloc" message on iSCSI
Hey Andrew, can you instrument the IO code a bit? It's possible that the iscsi stack is returning an error that UFS isn't catching. Or it's possible that iscsi stack is failing to return an error and just dropping the data packet. That could mean that UFS is assuming that the write is going through, but isn't either because it's not catching the error, or that iscsi is lying to it. -Alfred * Andrew Snow <andrew@modulus.org> [081002 22:28] wrote:> > > I am playing with an iSCSI device on FreeBSD client running UFS2 on the > device over a LAN. Everything works well until I reboot the iSCSI > server - the client pauses for a minute or so then continues working > after iSCSI server comes back. No I/O errors are reported. Everything > seems to work fine for a little while! > > But shortly afterwards, I get a panic with the message > > panic: ffs_valloc: dup alloc > > > It seems related to the length of the delay the iSCSI device is paused - > restarting the iSCSI target daemon process doesn't cause the problem but > rebooting the whole target box does cause it. > > 1. Could this be related to the patch Matt Dillon created years ago > which I found here? > > http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html > > > 2. Can anyone think of any other reason this might happen? I know I am > stretching UFS to the limits here, expecting it to pause and restart > after more than a minute of locked disk :-) However, since all I/O > eventually complete successfully and no errors are reported, I find it > suspicious. > > > Cheers > > - Andrew > > > ps. running latest iSCSI code 2.1 on latest 7-STABLE box. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-- - Alfred Perlstein