[Stgt-devel] SCC vs SES
Ming Zhang
blackmagic02881
Thu Jun 21 15:36:29 CEST 2007
On Thu, 2007-06-21 at 18:03 +1000, Mark Harvey wrote:
> Hello One and all.
>
> Just brushing up on the recent changes to the stgt with regards to the
> SCC module.
>
> The most recent draft doco at the T10 site I could locate is dated 12
> Sept 1997 (scc2r04.pdf)
>
> From my 10 minute read of these standards, the 'scc' device appears to
> be aimed at the RAID Disk array and fine grain control of disks within a
> RAID array (hot-swap spares, redirecting SCSI commands to a device
> within an array, etc).
>
> While this model will suit the existing SBC / MMC modules, the SES (SCSI
> Enclosure Service) model would IMO be a better 'fit'.
>
> i.e. The target 'owner' is an enclosure, rather than a SCSI Controller..
>
> This way, the enclosure can be parent to all devices within the target.
>
> Having the SES be the 'parent' for all LUN within the target, a SCC
> module could then become a LUN within the SES framework (if this
> functionality is required) to direct SCSI commands to the SBC/MMC type
> devices within the target.
>
> The SES model would be a better fit with regards to virtual libraries.
> i.e. Each stgt target is an Enclosure with x number of logical units
> within the enclosure.
>
>
> From a practical point of view - As there is no SCC unique code behind
> the SCC target, both the SCC or SES models will work.
>
> I could see potential issues where a (unknown / as yet untested) SCSI
> initiators finding a SCC controlling a set of LUNs which happened to be
> tape drives and/or medium changer may fail...
>
i would ignore the SCC and only take care about SES. actually one step a
time, have SMC and SSC in tgt already a big success. SES can be treated
as some enterprise feature added later.
>
> Thoughts ?
>
>
> Regards
> Mark Harvey
>
>
>
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel
More information about the stgt
mailing list