Re: [Scst-devel] Finer grain locking in scst_sysfs

[Shahar S. <sha...@ka...>]

On Feb 14, 2013, at 1:38 PM, "Bart Van Assche" <bva...@ac...<mailto:bva...@ac...>> wrote:

On 02/13/13 08:49, sha...@ka...<mailto:sha...@ka...> wrote:
During a mapping, SCST modifies both acg (if lun masking is used), and
tgt_dev lists (both under device and under session).
This means that both the device and the session need to be protected
since a command __will__ traverse the tgt_dev instances under the
session to map between lun and tgt_dev.

We split the mapping to:
• target create/remove - no quiesce needed, only operation which may
affect the target is target reset which takes the global lock.
• add/remove volume (from target or ini group) - both session and device
need to be quiesced due to commands such as reservation, sense, and
report luns which are used to synchronize across devices and sessions.
If this is a problem, we can refine this to using a reference count on
the session and device quiesce, or even using the session lock. This
will only affect the "special" IO commands such as report luns,
reservations etc.
• add/remove initiator from ini group - no quiesce needed since access
to the acn lists are done under global lock.



A corner case is the xcopy command (which may work on more than one
device). This is a problem only if there is native SCST work performed
on the device. AFAIK there is currently no such problem.

create/remove volume (this is done via scst_user) -
================================
We need to protect the device from IO command access.

Commands working on this volume can be protected by volume level quiesce
on remove, logically there can be no such commands on create.
Commands working on other volumes do not query the global command list,
so they cannot find this volume "by mistake"
Task managment commands which may take access to the volume are:
• Target reset: takes the global lock
• Clear/Abort task set: volume level quiesce protects us
• Lun reset: volume level quiesce protects us
• Nexus loss: takes the global lock
• Clea ACA: volume level quiesce protects us

Please keep in mind that trying to suspend other I/O while processing a task management function would lead to a deadlock if two task management commands are received concurrently from different initiators. So I think that trying to suspend other I/O while processing a command should be avoided. Maybe I just misunderstood what you wrote ?

Bart.


I was planning on implementing a device level suspend just like the global quiesce works. I see your point regarding the task management,