Nicholas A. Bellinger, on 08/22/2010 12:25 AM wrote:
It needs a complete redesign to become fast.
Secondly, not being the original author of drivers/scsi/scsi_tgt_*, I am
happy to do the work and submit the necessary patches to achieve the
desired goal. Also, considering now we have the TCM v4 HBA/DEV
abstraction with a fabric independent control path in
target_core_fabric_configfs.c, there suddenly new interest to build upon
tomo's and mnc'c original STGT work in drivers/scsi/scsi_tgt_*.c
Using struct scsi_cmnd allocation from a specially allocated struct
request_queue still my preferred method for doing this, unless tomo and
mnc state otherwise. Also if we need to change the request_queue from
being per struct Scsi_Host to struct scsi_device that is one thing that
will be fine. If we need to make more drastic changes to
drivers/scsi/scsi_tgt_if.c that is also fine.
That would be a bad design, because it would couple together
fundamentally separate things: target and initiator subsystems (server
and client, eg apache and firefox, sendmail and mutt, etc.). It would
make the code harder to maintain and more fragile for modifications. On
the user level it would lead to the need to have target mode core module
always loaded. It is already so with STGT if you use FC or SRP. With
them the only way to not have scsi_tgt loaded is to remove STGT on the
compilation time.
However saying that it needs a 'complete redesign', especially without
ever consulting or offering to creat patches with STGT guys is not how
mainline development functions.
Well, it isn't my habit to bother people asking something about what I
can find an answer myself. I have spent sufficient amount of time
hacking Linux kernel (>10 years, from which 8 in the target mode), so I
can read others C code as easy as a book.
I've already described which flaws I see in the STGT design and nobody
objected me (one of the objections I repeated above). You can find my
messages in the list archive. Isn't answering on exact critics a way how
a cooperative development is supposed to be done? If somebody comes with
a better solution for an existing problem is he supposed be ignored? Is
it the way how the mainline development functions?
In
contrast, interface provided by scst_user has just 3% overhead comparing
with fully in-kernel backend and allows to build storage capable of
handling 1,500,000 IOPSes (Kaminario).
Please understand that you are more than welcome to create your
own TCM subsystem plugin for your SCST kernel<-> user passthrough
interface so it can take advantage of all the drivers/target/ code has
to offer.
Well, please understand that you are more than welcome to stop
reinventing a wheel and instead just have the functionality and the
advantages you referring already long ago implemented in SCST and being
used to build (using your expression) records breaking storage products.
You are also more than welcome to add the only extra functionality LIO
has over SCST, ALUA, into SCST. Your patches are always welcome.
Vlad
--
To unsubscribe from this list: 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
