Re: Ang: Re: [Stgt-devel] Re: stgt a new version of iscsi target?

[Vladislav Bolkhovitin <vst@vlnb.net>]

Mike Christie wrote:
> johan@capvert.se 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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click