Re: Possible bug in open-iSCSI

Re: Possible bug in open-iSCSI

[Konrad Rzeszutek]

On Tue, Mar 10, 2009 at 12:34:55PM +0530, sushrut shirole wrote:
> 
> Hi All,

Hey Sushrut,

I am also cross-posting my response to the linux-scsi mailing list
in case they have insight in this problem.

> 	I am currently guiding few students who are working on unh-iSCSI
> target. Currently we are simulating some faults at a target side .
> Like we are adding an error injection module to unh-iSCSI , so that
> one can test how initiator behaves on particular error .
> 	as a part of it we injects a fault in report LUN size . where we
> report a wrong LUN size . ( Suppose a LUN is of size 2 gb we report it
> as a 4 gb ).(Microsoft and open-iSCSI initiators we are using ).When
> we try formatting this LUN on open-iSCSI initiator it formats this LUN
> . In fact it doesn't give any error when we try to read or lseek 4gb
> of data . But on Microsoft initiator we get an error when we try to
> format this LUN . So is this a bug of open-iSCSI or this is bug of
> read lseek ?

The Open-iSCSI does not investigate any SCSI commands (except the AEN which
gets is own special iSCSI PDU header).

What you are looking at is the SCSI middle-layer, or the block-device layer,
or the target not reporting an error, at being potentially faulty.
What Linux kernel does when you lseek to a location past 2GB and do a read,
is to transmute the request to a SCSI READ command.

That SCSI READ command (you can see what the fields look like when you
capture it under ethereal) specifies what sector it wants. Open-iSCSI
wraps that SCSI command in its own header and puts it in a TCP packet
destined to the target. The the target should then report a failure
(sending a SCSI SENSE value reporting a problem). Now it might be that SCSI
middle layer doesn't understand that error condition and passes it on as OK.
Or it might be that the target doesn't report a failure and returns garbage/null data.

What I would suggest is to do a comparison. Create a test setup where you
have a real 4GB LUN, do a lseek/read above 2GB and capture all of that
traffic using wireshark/ethereal. Then do the same test but with a 2GB LUN
that looks like a 4GB and see what the traffic looks like.

If it looks the same then somehow the target isn't reporting the right
error. Which implies that when Microsoft formats the disks they verify it - by
rereading the data they wrote in and failing if the doesn't match. Which might
not be what mkfs.ext3 does under Linux - look in the man-page to find out. But
by using lseek/read (or just do a dd with the skip argument - look in the manpage
for more details) a couple of times on the same sector and you should see
different data as well.

If the TCP dump looks different, and the target reports a error and the Linux kernel
doesn't do anything then it is time to dig through the code (scsi_error.c) to find
why Linux doesn't see it as. Make sure you do use the latest kernel thought - which as of
today is 2.6.29-rc7-git3. And if you do find the problem post a patch
on the linux-scsi mailing list.

> 
> --
> Thanks,

Hope this lengthy explanation helps in your endeavor.