On Thu, 2013-07-25 at 15:21 +0200, Tomas Molota wrote: > Nicholas, i did installation as its on this web page: > http://www.linux-iscsi.org/wiki/Downloads#LIO_Linux_SCSI_Target > it installed me kernel 3.10-rc5, i used patch, compiled and booted. But this version is not working at all with FCoE. > Everything looks ok, no errors nothing, but no host can find any LUN exported. When i boot with same config back to my original 3.9 kernel > Everything worsk ok (but with "_" error), ESXi find LUNs etc. Booted again to 3.10-rc5 and LUNs disapears in ESXi. Mmmmm, I don't recall any tcm_fc specific changes going into v3.10-rc code, so this issue your encountering with ESXi FCoE initiator and v3.10-rc5 FCoE target might actually be caused by some other fcoe/libfcoe breakage. In any event, it might be worthwhile to verify with the Linux FCoE initiator on the same setup, and report a bug to the FCoE folks. Thanks! --nab > And in 3.9 kernel source there is no such file like target_core_spc.c > Any help with this? Thanks > > S pozdravom / Best regards > > Tomas Molota > Chief Technology Officer > > > Parickova 18, 821 08 Bratislava, Slovakia > e-mail: tomas.molota@xxxxxxxxxxxxx > web: www.lightstorm.sk > phone: +421 2 32 400 011 > cell phone: +421 903 788 100 > > -----Original Message----- > From: Nicholas A. Bellinger [mailto:nab@xxxxxxxxxxxxxxx] > Sent: Thursday, July 25, 2013 1:14 AM > To: Roland Dreier > Cc: Tomas Molota; target-devel > Subject: Re: FCoE Target naming - help > > On Wed, 2013-07-24 at 09:36 -0700, Roland Dreier wrote: > > On Wed, Jul 24, 2013 at 8:11 AM, Tomas Molota > > <tomas.molota@xxxxxxxxxxxxx> wrote: > > > Hello, iam trying to use LIO as FCoE ALUA target and i have problem > > > with naming which LIO shows to initiators. What i see: > > > Vendor ID : LIO-ORG_ > > > Product ID: IBLOCK__________ > > > And our system has problem with "_" which are not allowed as name of > > > storage and its shows me error with this LUN as not supported > > > device. Is it possible somehow to change this option? > > > > Do you mean spaces where you write "_"? What do mean by "show to > > initiators"? If you mean the data in the INQUIRY response, then > > that's what the SCSI spec mandates. In SPC-4, for example, the vendor > > field is specified as: > > > > "The T10 VENDOR IDENTIFICATION field contains eight bytes of > > left-aligned ASCII data (see 4.3.1) identifying the vendor of the > > logical unit." > > > > where 4.3.1 says: > > > > "ASCII data fields described as being left-aligned shall have any > > unused bytes at the end of the field (i.e., highest offset) and the > > unused bytes shall be filled with ASCII space characters (20h)." > > > > Similarly for the product id fields. > > > > so according to the SCSI standards, padding those fields with spaces > > is required. > > > > Mmmm, then this is a bug in spc_emulate_inquiry_std() for VENDOR + MODEL fields. > > Thomas, can you please verify with the following patch..? > > --nab > > diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c > index 4cb667d..a4a29c6 100644 > --- a/drivers/target/target_core_spc.c > +++ b/drivers/target/target_core_spc.c > @@ -97,9 +97,12 @@ spc_emulate_inquiry_std(struct se_cmd *cmd, unsigned char *buf) > > buf[7] = 0x2; /* CmdQue=1 */ > > - snprintf(&buf[8], 8, "LIO-ORG"); > - snprintf(&buf[16], 16, "%s", dev->t10_wwn.model); > - snprintf(&buf[32], 4, "%s", dev->t10_wwn.revision); > + memcpy(&buf[8], "LIO-ORG ", 8); > + memset(&buf[16], 0x20, 16); > + memcpy(&buf[16], dev->t10_wwn.model, > + min_t(size_t, sizeof(dev->t10_wwn.model), 16)); > + memcpy(&buf[32], dev->t10_wwn.revision, > + min_t(size_t, sizeof(dev->t10_wwn.revision), 4)); > buf[4] = 31; /* Set additional length to 31 */ > > return 0; > > > -- > To unsubscribe from this list: send the line "unsubscribe target-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
