Re: Linux Virtual SCSI HBAs and Virtual disks

Aboo Valappil
2007-01-24T09:40:57Z

Douglas Gilbert wrote:
> Aboo Valappil wrote:
>
>> Hi Stefan Richter,
>>
>> Thanks everyone for their advice on this. As per your advice, I did the
>> following when the last user space target serving the scsi_host quits,
>> the queue command will do the following on the new commands coming through.
>>
>> sc->result = DID_NO_CONNECT << 16;
>> sc->resid = sc->request_bufflen;
>> set_sensedata_commfailure(sc); ---------------------
>> This sets the sense buffer with Device Not ready/Logical Unit
>> Commincation failure.
>> done(sc);
>>
>> The scsi_host will remain in the kernel. Let the EH thread handle the
>> queued commands (If any). If the user target wants to reconnects to the
>> same scsi_host, it can do so (Just re-run the user space target again
>> with same command line paramters). This connection from newly started
>> target will make the HBA healthy again and start serving IO.
>>
>> I implemented a new IOCTL to remove this scsi_host if the user
>> process really needs to. This removal will first finish all the SCSI
>> commands (With the above status results) queued on the scsi_host (If at
>> all) and then remove the scsi_host. Also the module unload will delete
>> all the scsi_hosts created after finishing all the commands queued with
>> the above status and sense information.
>>
>> I also implemented passing of sense code information from user space to
>> sense_buffer. A little more work needs to be done on this.
>> Also, I need to make sure that all the locking used inside is correctly
>> implemented to prevent dead locks and improve efficiency.
>>
>> The new version is available http://vscsihba.aboo.org/vscsihbav204.gz
>>
>
> A few observations from testing this version:
>
> # ./start_target.sh id=3 -files ../../zz_lun0 -v
> # lsscsi
> [0:0:0:0] disk Linux scsi_debug 0004 /dev/sda
> [1:0:0:0] disk VirtualH VHD 0 /dev/sdb
>
> So "id=3" doesn't look the target identifier. If not, what
> is it?
>

This is just an identification for the scsi_host created inside the
kernel. If you re-run the same command again with same id, the new
process would attach to the same scsi_host. This can be seen as two user
process serving the same virtual host bus adapter. If use a different
id with the same lun file, It will create a new scsi_host and it would
appear as the same LUN on a different host bus adapter.
.
It is not the target.
> Here is an attempt to fetch the Read Write Error Recovery
> mode page:
> # sdparm -p rw -vv /dev/sg1
> inquiry cdb: 12 00 00 00 24 00
> /dev/sg1: VirtualH VHD 0
> mode sense (10) cdb: 5a 00 01 00 00 00 00 00 08 00
> mode sense (10): Probably uninitialized data.
> Try to view as SCSI-1 non-extended sense:
> AdValid=0 Error class=0 Error code=0
>
>
>>> Read write error recovery mode page [0x1] failed
>>>
>
>
> That implies a sense buffer full of zeroes. The debug
> output from start_target.sh associated with that attempt:
>
> SCSI cmd Lun=00 id=2D CDB=12 00 00 00 24 00 00 00 08 00 00 00 00 00 00 00
> SCSI cmd Lun=00 id=2D completed, status=0
> SCSI cmd Lun=00 id=2E CDB=5A 00 01 00 00 00 00 00 08 00 00 00 00 00 00 00
> SCSI cmd Lun=00 id=2E completed, status=2
> SCSI cmd Lun=00 id=2F CDB=03 00 00 00 FC 00 00 00 08 00 00 00 00 00 00 00
> SCSI cmd Lun=00 id=2F completed, status=0
> SCSI cmd Lun=00 id=30 CDB=00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
> SCSI cmd Lun=00 id=30 completed, status=0
>
> So that is an INQUIRY [expected], MODE SENSE(10) [expected],
> REQUEST SENSE [what, no autosense??] and TEST UNIT READY
> [ah oh, error recovery??] sequence.
>
> Perhaps you could examine the way scsi_debug (or most
> other LLDs) does autosense. This modern technique (used
> for about the last 12 years) relieves the scsi midlevel
> of having to send a follow up REQUEST SENSE.
>
I shall look in the sdebug and see how it handles the Auto sense. What
is the scsi target does not give any sense informationx with a non zero
SCSI response?
Can I just make one up? I have modified it to give a sense of SK=06
(Illegal request), ASC=20(Invalid command Op code). May be looking at
the sdebug may give an idea.
> It would be easier to read those SCSI commands in the
> debug output if they were trimmed to their actual lengths
> (e.g. the INQUIRY is 12 00 00 00 24 00).
>
I will make it look better.
> Doug Gilbert
>