[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <639AD5C0020000A100050749@gwsmtp.uni-regensburg.de>
Date: Thu, 15 Dec 2022 09:07:28 +0100
From: "Ulrich Windl" <Ulrich.Windl@...uni-regensburg.de>
To: <haowenchao@...wei.com>
Cc: "open-iscsi" <open-iscsi@...glegroups.com>,
<linfeilong@...wei.com>, <liuzhiqiang26@...wei.com>,
<jejb@...ux.ibm.com>, <martin.petersen@...cle.com>,
<michael.christie@...cle.com>, "Chris Leech" <cleech@...hat.com>,
"Lee Duncan" <lduncan@...e.com>, <linux-kernel@...r.kernel.org>,
<linux-scsi@...r.kernel.org>
Subject: Antw: [EXT] Re: [PATCH 0/2] scsi:donot skip lun if inquiry
returns PQ=1 for all hosts
>>> Christoph Hellwig <hch@...radead.org> schrieb am 15.12.2022 um 08:06 in
Nachricht <Y5rHX95Vvl1aLhbp@...radead.org>:
> On Wed, Dec 14, 2022 at 03:08:44PM +0800, Wenchao Hao wrote:
>> When iSCSI initiator logged in target, the target attached none valid
>> lun but lun0. lun0 is not an valid disk, while it would response
>> inquiry command with PQ=1 and other general scsi commands like probe lun.
>> The others luns of target is added/removed dynamicly.
>
> I can't find any special casing of LUN0 in RFC7144, can you clarify
> where you think that treats LUN0 any differently than other transports?
Actusally I have no idea, but as a user of FC SAN systems I can remember a case when a storage system had to present a dummy LUN0 to enable hosts to find other LUNs (while LUN0 was never actually used). Maybe the client code was imperfect, I don't know.
>
> --
> You received this message because you are subscribed to the Google Groups
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to open-iscsi+unsubscribe@...glegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/Y5rHX95Vvl1aLhbp%40infradead.org
> .
Powered by blists - more mailing lists