lkml.org 
[lkml]   [2002]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IDE/ATAPI in 2.5
>From alan@lxorguk.ukuu.org.uk Sun Jul 14 17:35:44 2002


>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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.024 / U:0.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site