lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Nov 2012 16:20:46 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Michal Nazarewicz <mina86@...a86.com>
CC:	Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joel Becker <jlbec@...lplan.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Subject: Re: [RFC][PATCH] fs: configfs: programmatically create config groups

On 11/26/2012 06:54 PM, Michal Nazarewicz wrote:
> On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
>> Wouldn't say that. It may adds complexity on another level. The target
>> subsystem has the same problem with adding luns and there seems nothing
>> wrong with having lun3 and 4 and leaving 0 and 1 unsued.
>
> That's not what Wikipedia claims though (from
> <http://en.wikipedia.org/wiki/Logical_Unit_Number>):
>
> 	LUN 0: There is one LUN which is required to exist in every
> 	target: zero. The logical unit with LUN zero is special in that
> 	it must implement a few specific commands, most notably Report
> 	LUNs, which is how an initiator can find out all the other LUNs
> 	in the target. But LUN zero need not provide any other services,
> 	such as a storage volume.
>
> That's why I proposed solution where one needs to have continuous
> numbering of LUNs.  I'm not an expert on SCSI though.

Let me quote "4.6.4 Minimum LUN addressing requirements" of SAM4:

| All SCSI target devices shall support LUN 0 (i.e., 00000000
| 00000000h) or the REPORT LUNS well-known logical unit. For SCSI
| target devices that support the hierarchical addressing model the LUN
| 0 or the REPORT LUNS well-known logical unit shall be the logical
| unit that an application client addresses to determine
| information about the SCSI target device and the logical units
| contained within the SCSI target device.

Nab, I think not having LUN0 configured as long as REPORT LUNS says
which luns are available is fine. Target seems to work on linux without
it and SAM4 does no claim otherwise unless I miss interpret it. Any
opinion on this from your side?

>
>> With the tcm gadget I get:
>>
>> |scsi 0:0:0:2: Direct-Access     LIO-ORG  RAMDISK-MCP      4.0  PQ: 0
>> ANSI: 5
>> |scsi 0:0:0:3: Direct-Access     LIO-ORG  FILEIO           4.0  PQ: 0
>> ANSI: 5
>>
>> You notice :2 and :3 instead :0 and :1. While should be there something
>> wrong with this?
>
> It may be that it works on Linux but fails on some other systems (or
> even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
> knowledge of it is (embarrassingly) minimal.

Sure but still. You limit the user to create lunX folders where X can
be 0..255 for instance. If the user chooses not create lun0, why force
him?

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ