[stgt] RFC [patch] README.passthrough v1 (2nd send)
Mark Harvey
markh794 at gmail.com
Thu Aug 19 08:23:37 CEST 2010
On Thu, Aug 19, 2010 at 11:01 AM, Nicholas A. Bellinger
<nab at linux-iscsi.org> wrote:
> On Thu, 2010-08-19 at 10:28 +1000, Mark Harvey wrote:
>> On Thu, Aug 19, 2010 at 9:47 AM, Nicholas A. Bellinger
>> <nab at linux-iscsi.org> wrote:
>> >
>> > Hmmm strange.. Checking on Fedora 11 (v2.6.30), RHEL6 B1 (v2.6.32),
>> > OpenSuse 11.2 (v2.6.31), SLES 11 (v2.6.27), and Debian Lenny VMs
>> > (v2.6.35 from lio-core-2.6.git/lio-4.0), and I do see the
>> > proper /dev/bsg/H:C:T:L device nodes matching the available struct
>> > scsi_device.
>> >
>> > However, I do recall one seing the BSG H:C:T:L device nodes appear
>> > in /dev/ instead of /dev/bsg/ before. I don't recall on which
>> > environment this was, but I think it may have been some version of
>> > Ubuntu..?
>> >
>> > Just to double check on your system, a 'cat /proc/kallsyms | grep bsg'
>> > produces symbols for the kernel built-in BSG kernel code, yes..?
>> >
>> > Best,
>> >
>> > --nab
>>
>> Many thanks for the pointers..
>>
>> Found an SLES-11 VM with bsg.. I'll update the doc now I've got
>> something to test.
>> Also allow me to put in 'how to identify if your OS has bsg configured' :)
>>
>
> :-)
>
>> Next Q. if I may.
>> Do you / can anybody on this list offer a short (one liner?) summary
>> of advantages of bsg over sg ?
>> I'll now hit google with the Q too..
>>
>
> So the main difference from the perspective of a userspace space app is
> going from using include/scsi/sg.h:struct sg_io_hdr to using
> include/linux/bsg.h:struct sg_io_v4. On modern kernel code, under the
> hood in the kernel both drivers/scsi/sg.c and block/bsg.c use struct
> request based I/O via blk_get_request() to obtain a struct request, and
> blk_execute_rq_nowait() to asychronously queue the I/O to the underlying
> backstore.
>
> BSG exposes more raw functionality (but certaily not all) of the modern
> Linux Block layer code. This includes the ability to do BIDI commands
> and support for legacy SG_IO ioctls in block/bsg.c:bsg_ioctl().
>
> Note that not all of the the structure members in struct sg_io_v4 can
> safely be used with current mainline code. For example, having a 32-bit
> userspace passing up 32-bit pointers currently need a patch to require
> proper conversion to 64-bit struct scatterlist memory. The first half
> of this patch is here:
>
> http://groups.google.com/group/linux-iscsi-target-dev/browse_thread/thread/6b9f8a08f78067dc/6330a5897203854a?lnk=gst&q=BSG#6330a5897203854a
>
> This issue came up again between Tomo-san and myself last week, and we
> agreed that the patch to make 32-bit user + 64-bit kernel work with BSG
> scatterlists would not be pretty, but that it does need to be fixed in
> order to properly support the QEMU-KVM SCSI-BSG MegaSAS SGL passthrough.
> This is the code that has been being going in parallel with the recent
> multi-fabric TCM_Loop Virtual SCSI LLD develpments for STGT, which can
> be found here to give more of an idea how BSG functions.
>
> http://git.kernel.org/?p=virt/kvm/nab/qemu-kvm.git;a=blob;f=hw/scsi-bsg.c;hb=refs/heads/scsi-bsg
>
> Best,
>
> --nab
OK, I'm having some problems with 1.0.7 build attempting to configure
a bsg device.
OS is SLES 11 x86_64
Linux mhvtl5 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100
x86_64 x86_64 x86_64 GNU/Linux
# lsscsi -g
[3:0:1:0] tape IBM ULT3580-TD5 550V /dev/st0 /dev/sg2
# ls -l /dev/bsg/
total 0
crw-rw---- 1 root root 253, 0 2010-08-15 13:15 0:0:0:0
crw-rw---- 1 root root 253, 1 2010-08-15 13:15 2:0:0:0
crw-rw---- 1 root root 253, 10 2010-08-17 12:02 3:0:0:0
crw-rw---- 1 root root 253, 2 2010-08-17 12:02 3:0:1:0
crw-rw---- 1 root root 253, 7 2010-08-17 12:02 3:0:10:0
crw-rw---- 1 root root 253, 8 2010-08-17 12:02 3:0:11:0
crw-rw---- 1 root root 253, 9 2010-08-17 12:02 3:0:12:0
crw-rw---- 1 root root 253, 3 2010-08-17 12:02 3:0:2:0
crw-rw---- 1 root root 253, 4 2010-08-17 12:02 3:0:3:0
crw-rw---- 1 root root 253, 5 2010-08-17 12:02 3:0:4:0
crw-rw---- 1 root root 253, 11 2010-08-17 12:02 3:0:8:0
crw-rw---- 1 root root 253, 6 2010-08-17 12:02 3:0:9:0
# tgtadm --op new --mode target --tid 1 -T iqn.2010-08.com.nbusyd:mh
# tgtadm --op new --mode logicalunit --tid 1 --lun 1 --bstype=bsg
--device-type=pt -b /dev/bsg/3:0:1:0
tgtadm: invalid request
All the syslog shows is:
tgtd: bs_sg_open(361) Not recognized /dev/bsg/3:0:1:0 as an SG device
An attempt to use the 'sg' type works fine:
# tgtadm --op new --mode logicalunit --tid 1 --lun 1 --bstype=sg
--device-type=pt -b /dev/sg2
#
# tgtadm --op show --mode target
Target 1: iqn.2010-08.com.nbusyd:mhvtl
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00010000
SCSI SN: beaf10
Size: 0 MB
Online: Yes
Removable media: No
Backing store type: null
Backing store path: None
Backing store flags:
LUN: 1
Type: (null)
SCSI ID: IET 00010001
SCSI SN: beaf11
Size: 0 MB
Online: Yes
Removable media: No
Backing store type: sg
Backing store path: /dev/sg2
Backing store flags:
Account information:
ACL information:
The sg_inq utility doesn't appear to like the /dev/bsg/ devices either.
# rpm -qi sg3_utils
Name : sg3_utils Relocations: (not relocatable)
Version : 1.27 Vendor: SUSE LINUX
Products GmbH, Nuernberg, Germany
Release : 17.7 Build Date: Sat 21 Feb
2009 12:23:21 PM EST
Mind you, the sg3_utils homepage has this "From lk 2.6.28 bsg devices
can also be used (e.g. /dev/bsg/3:0:0:0 )."
Cheers
Mark
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the stgt
mailing list