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 <[EMAIL PROTECTED]> [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 "[EMAIL PROTECTED]"
--
- Alfred Perlstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
