Re: [Scst-devel] setting of SCSI id

[wk <wit...@op...>]

Vladislav Bolkhovitin wrote:
> wk wrote:
>> Vladislav Bolkhovitin wrote:
>>> Hi,
>>>
>>> wk wrote:
>>>> Hi Vladislav,
>>>>
>>>> Our QA team has tested several scenarios with changing parameters of 
>>>> iSCSI virtual disks - like changing size of virtual disk through lvm 
>>>> tools (on the iSCSI target side).
>>>> They noticed that with IET and Windows as iSCSI initiator it is 
>>>> possible to resize logical volume - and some programs for Windows 
>>>> doesn't lose transmissions started before. But with SCST iSCSI some 
>>>> of these programs *always* loses its transmissions. With this patch 
>>>> I've sent - the QA team says that now SCST iSCSI works like IET 
>>>> (from the Windows user point of view) - so it doesn't break the 
>>>> connection.
>>>>
>>>> For doing such operations as resize we need of course to detach 
>>>> virtual disk from iSCSI target, resize it and attach it to LUN again.
>>>>
>>>> Here is the scenario of testing:
>>>>
>>>> 1. configuring iSCSI target (SCST or IET) with some VDISK
>>>> 2. on the Windows side - configuring disk with iSCSI inititator
>>>> 3. windows: - starting copying very big file
>>>> 4. detach of VDISK on iSCSI target - from IET of SCST
>>>> 5. reconfiguration of VDISK on iSCSI target side (i.e. resizing)
>>>> 6. attach just reconfigured VDISK on iSCSI target again
>>>>
>>>> The steps 4-6 are managed by script - so they are relatively fast.
>>>>
>>>> Probably there is somewhere the problem - during reattachment of 
>>>> disk - and as effect Windows applications looses its connections?
>>>>
>>>>
>>>> My patch in fact doesn't remove the original code of generation SCSI 
>>>> id - it only allows to set your own id, but if you don't set it 
>>>> manually - it will use the original method.
>>> It's hard to believe that the current SCSI ID generation code can 
>>> cause such consequences, because the generated ID is always the same 
>>> for the same device name. I believe, the cause is in the 
>>> corresponding INQUIRY handling code. I'm currently fixing the similar 
>>> issue, so let's return to it after I finish.
>>
>> It seems like I'll have to explain the whole situation.
>>
>> We needed the possibility of setting our own SCSI ID in iSCSI. We are 
>> using some kind of failover solution where there is required identical 
>> SCSI ID on failover nodes. For this purpose patch I've sent earlier 
>> has been done.
>> During the comparison testing of two iSCSI implementations: IET and 
>> SCST   it seemed like IET was able to keep their connections up with 
>> initiator, but SCST worked properly only with our patch. It might be 
>> very particular situation that SCST with our patch worked fine without 
>> losing connections, because few days later we cannot repeat those 
>> tests with the same results: SCST were losing their connections 
>> independent of we were using original SCST or patched one. So, the 
>> conclusion that changing SCSI ID will help with keeping up established 
>> connections was wrong. The problem lies somewhere else.
> 
> This is what I meant. But questions about ability to set manual SCSI ID 
> as well as USN keep rising again and again. This is why I suggested to 
> return to your patch after the code it touches will be proved to be 
> correct. Then it would be good if your patch also will be extended to 
> allow to set USN.
> 
>> Thank you for the answers, and sorry for the fuss.
>>
>> p.s. for testing we were using "sequential tests" from "Bart's Stuff 
>> Test" programm on the Windows system.
> 
> I'm not aware about it. Can to send me the link, please? I'm looking for 
> good small test for Windows.

Hi Vladislav,

Below is the direct link for "Bart's Stuff Test" we were using for tests:

http://www.nu2.nu/download.php?sFile=bst514.zip

best regards,
Witold Kowolik