use dedicated storage for scsi_debug LUNs
I'm using scsi_debug to implement and test tools for xen-scsiback. Today I discovered that each LUN uses the very same storage, as described in the docs. What would it take to optionally use dedicated storage for each LUN?
This is how I load scsi_debug:
modprobe scsi_debug add_host=4 dev_size_mb=4 max_luns=4 num_parts=4 num_tgts=4 vpd_use_hostno=1
Olaf
Quoted 7 lines · Olaf Hering
I'm using
scsi_debugto implement and test tools for xen-scsiback. Today I discovered that each LUN uses the very same storage, as described in the docs. What would it take to optionally use dedicated storage for each LUN?This is how I load
scsi_debug:
modprobescsi_debugadd_host=4 dev_size_mb=4 max_luns=4 num_parts=4 num_tgts=4 vpd_use_hostno=1
Olaf,
Just having a quick look: the fake_storep, dif_storep and map_storep heaps would need to be per LU; IOWs placed in struct sdebug_dev_info. Also atomic_rw would need to be placed in that structure.
To be backward compatible to what the scsi_debug driver does now (i.e. shares storage) accessor functions might be employed to hide whether the global or per LU instance is being handled.
Handling the inevitable ENOMEM errors might be a bit tricky especially since extra LUs and hosts can be added dynamically via sysfs.
So it is possible. The stock answer has typically been that you should probably be using the target subsystem for that. Thoughts?
Doug Gilbert
Quoted 3 lines · Douglas Gilbert
So it is possible. The stock answer has typically been that you should probably be using the target subsystem for that. Thoughts?
Is the target subsystem capable of stacking? What I need for xen-scsiback is a bunch of true SCSI devices. Due to lack of hardware, scsi_debug looks like the obvious choice.
I will see if I can come up with a patch. Thanks for your input.
Olaf
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Olaf" == Olaf Hering <[email protected]> writes:
Quoted 2 lines · Douglas Gilbert
Quoted 2 lines
So it is possible. The stock answer has typically been that you should probably be using the target subsystem for that. Thoughts?
Olaf> Is the target subsystem capable of stacking? What I need for Olaf> xen-scsiback is a bunch of true SCSI devices. Due to lack of Olaf> hardware, scsi_debug looks like the obvious choice.
I agree with Doug. The target code is much more comprehensive than scsi_debug. You can set up file/disk/ram-backed SCSI LUNs on your machine without the need for any hardware .
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 3 lines · Martin K. Petersen
I agree with Doug. The target code is much more comprehensive than
scsi_debug. You can set up file/disk/ram-backed SCSI LUNs on your machine without the need for any hardware .
Does that target code offer what scsi_debug offers, a bunch of stuff listable with 'lsscsi'? The latter can be passed to backstores/pscsi.
Olaf
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Olaf" == Olaf Hering <[email protected]> writes:
Olaf> Does that target code offer what scsi_debug offers, a bunch of Olaf> stuff listable with 'lsscsi'? The latter can be passed to Olaf> backstores/pscsi.
Yes.
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 5 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Olaf" == Olaf Hering <[email protected]> writes:
Olaf> Does that target code offer what
scsi_debugoffers, a bunch of Olaf> stuff listable with 'lsscsi'? The latter can be passed to Olaf> backstores/pscsi.
Yes.
Indeed, with /backstores/fileio/ and /loopback/.
It would be nice if one could specify a fixed identifier for each fileio during creation. Right now the symlinks in /dev/disk/by-*/* are all random. Its not easily possible to map file_or_dev=$file to the resulting SCSI device.
Olaf