Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1610018 > unrolled thread

scsi_debug: shared dev context, BUG or FEATURE?

Back to article view | Back to linux.kernel

Contents

  scsi_debug: shared dev context, BUG or FEATURE? Dmitry Monakhov <dmonakhov@openvz.org> - 2017-03-27 19:50 +0200
    Re: scsi_debug: shared dev context, BUG or FEATURE? "Martin K. Petersen" <martin.petersen@oracle.com> - 2017-03-28 03:50 +0200
      Re: scsi_debug: shared dev context, BUG or FEATURE? Dmitry Monakhov <dmonakhov@openvz.org> - 2017-03-28 12:40 +0200

#1610018 — scsi_debug: shared dev context, BUG or FEATURE?

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. 

[toc] | [next] | [standalone]

#1610243

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

[toc] | [prev] | [next] | [standalone]

#1610547

"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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web