>Try doing the following in SCSI
>- Device managed storage layout "Allocate x blocks close to handle y
>and give me a new handle"
You don't want do do this in SCSI because it is a task of a layer above SCSI.
>- Per I/O request readahead hints (please read on xyzK , please dont
>readahead)
Again: this is a task of a layer above SCSI.
In some cases, where you might refer to medium access level read ahead,
this is done by implementing tagged SCSI command queueing.
>- Per I/O request writeback hints (write back cache is ok, write back
>cache is ok only if NV, don't bother caching, streaming I/O
> hint)
Again: this is a task of a layer above SCSI. See Solaris and FreeBSD as
examples.
It would help if you first do some homework and read some decent kernel
sources to understand how a kernel needs to be layered to implement
e.g. Storage/FS/kernel/user interface layering.
Then use e.g. 'iostat' to see how overlapping disk I/O is done.
>I have controllers which can do most of the above. I don't want to talk
>scsi to them and spend all my cpu time faking, decoding and recoding
>command blocks, spoofing error handling and the like.
>Its simply inappropriate to consider the SCSI command set as a high
>level interface for block and related I/O.
It looks like you never did metering tests to see what amount of time
is needed to handle the SCSI protocol.
I did many tests when implementing RSCSI. Even when you include TCP/IP
times, the overhead is <= 100 µs per SCSI command.
>As to your comments on sg. Everyone except you happened to think that
>Doug Gilberts very nice sg changes were the right path. I still think it
>was the right decision.
Not knowing what is bad may make people believe that something is good.
>> If this discussion stays as it currently looks like, it does not make
>> sense for me to try to find a better solution. Let me call it this
>> way: this thread was just another proof that it is not possible to
>> have a technical based solution with the Linux folks. It seems t be >
>> just a waste of time :-(
>The Linux development process aggressively filters bad ideas.
It definitely did not help 4 years ago, when the sg problem did came up.
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/