[stgt] [PATCH 1/2] tgt-admin: check if direct-device exists before allocating it

[ronnie sahlberg]

On Fri, Sep 12, 2008 at 6:30 PM, Tomasz Chmielewski <mangoo at wpkg.org> wrote:
> ronnie sahlberg schrieb:
>>
>> On Fri, Sep 12, 2008 at 12:25 AM, Tomasz Chmielewski <mangoo at wpkg.org>
>> wrote:
>>>
>>> I will if it's not fixed when I send a bigger patch.
>>>
>>> To not duplicate work, the changes I'm working on currently are:
>>>
>>> - allow setting write caching per lun,
>>> - allow setting scsi_id, scsi_sn, product_id etc. other parameters, per
>>> lun
>>> - useful if one uses multipathd, but not only
>>>
>>> Any users of these features out there?
>>>
>>
>> Excellent. I will use these features!
>>
>> I would also like to be able specify the LUN for each backingstore,
>> not just that they always start at 1 and increment one by one.
>
> Yeah, I was thinking about this too.
>
> It will be needed if we want to have a predictable lun numbering when:
> - more than one lun/backing-store is used
> - they have different parameters set
>
> However, this feature will be added later.
>
>
>> I would like to specify the device type to use for each backingstore.
>> It currently assumes everything is a disk device.
>
> What --params= is needed here?

--device-type=cd


>
>
>> later I would also like to be able to configure for individual LUNs
>> things like :
>>    Only these initiators can see/access this particular LUN.
>
> Is it at all possible? To allow initiators access to specified LUNs only? In
> tgtd, iSCSI RFCs etc.?

Yes. All enterprise targets support features like this.
You implement access control down on the LUN level, not on the target level.

With this and when you have multiple targets on a single host you may
also want some changes we may need later.

Example :
Sometimes you want to create one dedicated target for each initiator.
On each target you create a few LUNs and you set up the ACLs for that
LUN that only that particular initiator can access it.
Some people want to set their systems up like this.

You would then end up with 100 targets, behind which there are a few LUNs.
For one particular Initiator, lets call it host Foo, which runs Linux.

When we connect to the target to do discovery, Foo would see 100
different targets, but there would only be one single target behind
which there would be a LUN.
99 of the targets would report that there were no luns at all when the
initiator does a REPORT LUNS.


This is problematic since  Linux (and other) initiators often try to
be helpful so when they discover a target being logged into that has
no luns, it will go into a loop where it tries a new REPORT LUNS every
30 seconds,   for all those 99 targets we cant access.
This becomes a n-squared amount of traffic and eventually your network
is hosed by initiators sending REPORT LUNS left right and centre.


To solve this, enterprise targets all have a special setting that means :
When an initiator performs a SendTarget,   dont report ALL the
targets. Only report back those targets where there is at least 1 LUN
available that that particular initiator can access.




>
>
>>    These particular initiators can see/access this LUN   but the LUN
>> is read-only for them.
>
> As above - is it possible?

Yes.   All enterprise targets have had lun-masking since ages.  EMC
used to call it the VCMDB   or just lun-masking dependent on which
target platform you used.
This was a binary   can access lun/lun can not be accessed (and does
not show up in REPORT LUNS)

Cisco MDS9000 san switch/bridge introduces a more fine grained masking
  where instead of
Can Access/Can NOT Access
you suddenly got
Can Access/Can Access but read-only/Can not access.


This was popular and most target vendors started following this and
adding it to their targets.
It is useful.


>
>
>> When you design the algorithms for setting the serial numbers
>> automatically,    leave some reserved space in the field for
>> snapshots.
>> If in the future STGT gets the ability to snapshot a lun or a set of
>> luns, the snapshots should have different serial numbers than the
>> original production lun.
>
> Snapshots? Sounds like job for LVM?
> I'm not sure if we should go that far.

To re-attach the snapshot back to the production LUN  and make it
possible to re-sync the snapshot back to the production lun
efficiently would require a new backend.
All enterprise target vendors have features like this.
--
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