Re: Possible bug in open-iSCSI
Another test might be to take the filesystem out of the equation. Use 'dd' or 'dt' to write out past the 2GB mark and see what error results. Don On Wed, Mar 11, 2009 at 4:42 AM, sushrut shirole wrote: > Thanks a lot .. ill let u know about this .. > > 2009/3/10 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. >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Possible bug in open-iSCSI
Thanks a lot .. ill let u know about this .. 2009/3/10 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. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Possible bug in open-iSCSI
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Possible bug in open-iSCSI
Hi All, 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 ? -- Thanks, Sushrut Shirole Dev Engineer. Calsoft pvt. ltd. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
