On 12/24/12 08:33, sha...@ka... wrote:
> We are using SCST in a clustered SSD storage using FC and iSCSI
> connectivity.
> We are seeing problems when we attempt to perform multiple volume mappings.
> By problems I mean 2 things:
> 1. I/O is quiesced during these operations
> 2. Initiators get unit attentions due to the mapping changes which cause
> a lot of noise
>
> I reviewed the implementation of scst_sysfs and this seems to be by
> design, since during these operations both SCST mutex is taken and IO is
> quiesced.
>
> Are there any plans to introduce a finer grain locking/quiesce to these
> operations?
> An example would be that during mapping of volume V to host H1, host H2
> which is already mapped to V should not be affected. Another even more
> severe example would be if host H2 would have been mapped to volume V2
> which is not related to the new mapping.
The SCST data structure that contains the information necessary to
process a SCSI command is called struct scst_cmd. That data structure
does not only contain scalar variables but also pointers to several
other SCST objects, e.g. the SCST session, the SCST device and the SCST
LUN associated with a command. It is essential that all these objects
remain to exist while the SCSI command is being processed. There are two
ways to realize that:
- Reference counting - increase a reference count in each of the
mentioned objects before starting to process a command and decrease
these reference counts again after command processing finished.
- I/O quiescing. Suspend I/O before removing any of the objects the
scst_cmd structure references to.
In SCST the second approach has been chosen because it makes it safe to
access several internal data structures during I/O processing without
having to perform any locking (see e.g. scst_report_luns_local()).
So while it may be possible to avoid I/O quiescing when new devices are
added to SCST, quiescing is unavoidable when removing a device or when
changing the LUN masking configuration.
Bart.
|
