scsi_debug: shared dev context, BUG or FEATURE?

scsi_debug: shared dev context, BUG or FEATURE?

[Dmitry Monakhov]

Hi scsi_debug has very strange structure
from one point it supports dynamic number of devices
but from other point context is common for all devices:
 - dif_storep (array of t10 dif tuples)
 - map_storep (block map for thinprovision)
 - fake_storep (in memory data storage)
 - sdebug_q_arr (queue array)
So basically we may have many devices with single context which refers
common data. Are any sane reason to share context between devices?
Who use such behaviour?

IMHO this is a pure bug. Please correct me if I'm wrong, I'll plan to
fix that by allocation separate context for each dev. 

Re: scsi_debug: shared dev context, BUG or FEATURE?

[Martin K. Petersen]

Dmitry Monakhov <dmonakhov@openvz.org> writes:

Dmitry,

> scsi_debug has very strange structure from one point it supports
> dynamic number of devices but from other point context is common for
> all devices:

> So basically we may have many devices with single context which refers
> common data. Are any sane reason to share context between devices?
> Who use such behaviour?

As the name implies, scsi_debug was conceived to debug the SCSI layer.
Among other things, the intent was to be able to test hundreds of
controllers and LUNs without having physical hardware or storage to back
that up. Plus to have a target whose reporting could easily be tweaked
to test the SCSI core code.

So that's the reason for the oddball shared buffer setup. scsi_debug
wasn't really meant to be a "useful" storage target.

If you want something with a per-device backing store I suggest you look
at the SCSI target subsystem. With tcm_loop and ramdisk you get
essentially the same thing as scsi_debug. With the added bonus that you
can use files or block devices if you actually want the data to be
persistent.

> IMHO this is a pure bug. Please correct me if I'm wrong, I'll plan to
> fix that by allocation separate context for each dev. 

I don't have a problem with allowing it as an option as long as the
original behavior can be preserved. But again, I think target mode is a
better bet if you actually care about what's being stored on the
"media".

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: scsi_debug: shared dev context, BUG or FEATURE?

[Dmitry Monakhov]

"Martin K. Petersen" <martin.petersen@oracle.com> writes:

> Dmitry Monakhov <dmonakhov@openvz.org> writes:
>
> Dmitry,
>
>> scsi_debug has very strange structure from one point it supports
>> dynamic number of devices but from other point context is common for
>> all devices:
>
>> So basically we may have many devices with single context which refers
>> common data. Are any sane reason to share context between devices?
>> Who use such behaviour?
>
> As the name implies, scsi_debug was conceived to debug the SCSI layer.
> Among other things, the intent was to be able to test hundreds of
> controllers and LUNs without having physical hardware or storage to back
> that up. Plus to have a target whose reporting could easily be tweaked
> to test the SCSI core code.
>
> So that's the reason for the oddball shared buffer setup. scsi_debug
> wasn't really meant to be a "useful" storage target.
>
> If you want something with a per-device backing store I suggest you look
> at the SCSI target subsystem. With tcm_loop and ramdisk you get
> essentially the same thing as scsi_debug. With the added bonus that you
> can use files or block devices if you actually want the data to be
> persistent.
Wow this is really awesome. This is exactly what I need. Thank you.
>
>> IMHO this is a pure bug. Please correct me if I'm wrong, I'll plan to
>> fix that by allocation separate context for each dev. 
>
> I don't have a problem with allowing it as an option as long as the
> original behavior can be preserved. But again, I think target mode is a
> better bet if you actually care about what's being stored on the
> "media".

>
> -- 
> Martin K. Petersen	Oracle Linux Engineering