Re: [Scst-devel] Fwd: Re: linuxcon 2010...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux