RE: [PATCH v2] scsi: target: core: check SR field in REPORT LUNS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

>>> I'm a bit concerned about things inadvertently breaking if we return an empty list for the well known LUNs.
> >
>> According to SPC we shall report an empty list if there is no well-known LUNS.
>> FreeBSD has the same logic in REPORT LUNS handling. SCST does not support SELECT_WELLKNOWN case at all.
>> 
>> I don't know the history of the existing behaviour to send always LUN0 instead of empty list. Probably it was
>> for the SCSI_SELECT_ALL_ACCESSIBLE(0x02) case, where SPC allows LUN0. My patch keeps it for the 0x00, 0x02, 0x11 cases.
>> Thus, I believe it does not break the backward compatibility.

>Will this change require users to update their LUN configuration? Some 
>initiator operating systems require presence of a dummy LUN 0. Although 
>I agree that it is cleaner not to provide a hardcoded LUN 0, I think 
>Martin is concerned about this patch potentially breaking existing 
>configurations and causing frustration among LIO users.

No reconfiguration on initiator side is required.
W-LUN is a specific LUN for the specific SCSI target device that is well known
for the Initiator. Generic Linux TCM does not have W-LUNs. Some storage
systems based on Linux TCM may have W-LUNs. But then they shall / already have
its own handling of REPORT LUNS command.
Basically, it is an error to report LUN0 as W-LUN for the Initiator that
expects some other numbers.

BR,
 Dmitry




[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux