Mike Christie wrote:
johan@xxxxxxxxxx wrote:
I, and I suppose a lot of other people, would like know how you look
at the
HW support on the Fc side? I don´t know what you mean now, when you talk
about HW target support,
For qlogic FC, it is the same as scst at this point, except we are based
off the mainline qla2xxx driver.
Actually, this is not completely true and could mislead people. Stgt is
*not* the same as scst at this point and, I think will not be for at
least considerable amount of time.
They are the same only on a basic subset of functionality, which I would
call "fast path", and only for block devices that are could be
considered stateless, i.e. on which the result of a SCSI command's
execution isn't dependent on the current state of the device. For, eg,
tapes this isn't true, because on such devices the current state, like
block size, changes the result of the command a lot, so it shall be
honored and special handling of Unit Attention conditions shall be done.
For example, all UAs from a device shall be delivered to all connected
initiators, not only to one of them who happens to execute the command
with UA result. Another example is when one initiator changes state of
the device. After that all other initiators shall receive appropriate
UA, i.e. the mid-layer shall generate it, because for the device all
initiators act as one initiator (nexus) and the device is not able to
distinguish between them to perform all necessary SCSI handling. Thus,
the mid-layer has to do it. Not doing so is dangerous and could lead to
data corruption and loss. The same is true for "advanced" commands like
RESERVE/RELEASE, which also have to be "emulated" by the mid-layer.
Also, currently stgt doesn't care much about task management.
Scst from the very beginning was targeted for SCSI tapes exported via
hardware targets and was designed with all that very complicated staff
in mind. Most of scst complexity is caused by handling of it as well as
by attempt to make that handling at most performance effective way. For
example, on the fast path, no task management and UA-related locks are
taken, although this is done on the way, which could be considered a bit
unusual or extravagant, but effective.
Thus, to resume, the following important features are missed in stgt
comparing to scst:
- Task management
- SCSI handling/emulation required for statefull SCSI devices (tapes,
etc.)
- Scst has some performance advantages over stgt, at least, on
hardware targets, because it allows internal handling in SIRQ context as
well as doesn't need user space program, so it eliminates additional
context switches (at least 3 per command for WRITEs and 2 per command
for reads plus switches to user space daemon, probably, 2 per command).
5 context switches per command looks too much for me, especially
considering how little work is done on each context. It means ~15000
CS/sec on regular 200Mb/sec link with 64K block size. Additionally,
kernel only commands execution allows direct access to page cache, which
is GREAT performance improvement, because in architecture with user
space daemon the data should be copied several times between kernel and
user space. Or, do I miss anything?
- Access and devices (LUNs) visibility management. It allows for an
initiator or group of initiators to have different set of LUs, each with
appropriate access permissions. This feature provides HUGE usability,
people who tried it will confirm that.
- Support for most SCSI devices, namely tapes, processors (SCSI type
3), CDROM's (SCSI type 5), MO disks (SCSI type 7), medium changers (SCSI
type 8) and RAID controllers (SCSI type 0xC)
- Stability. Current SCST (0.9.3-pre2) is quite stable, as far as I
know only task management has some unfixed flaws.
Those are what I've noticed on a brief review. It's possible that I
missed something. For example, stgt seems doesn't have internal commands
serialization, so I suspect that if some initiator mixes READs and
WRITEs on some targets it will be possible that order of the commands
execution will be broken, because WRITE command have additional phase ,
when the command's data from the initiator is sent to the target. During
it subsequent READs could be executed out of order. The result could be
data corruption.
From other side, stgt has not too much advantages over scst.
Technically, I, personally, see only few such advantages. One of them is
support for putting block commands directly to the device request queue.
I'm going to fix this in the next version (I hope nobody will blame me
if I borrow this code from stgt :) ). Another one is support for
different "protocols", although I have not understood which ones, except
SCSI, are going to be there.
Actually, we would greatly appreciate if Mike or Christoph will tell us
what is so wrong in scst on their opinion, so they started they own new
project. (I'm not considering motivation like "I want to make my own in
any case" seriously). Is scst too complicated? Do you think stgt will be
simpler with all those features implemented?
Vlad
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
