Messages in this thread | | | Date | Sun, 14 Jul 2002 21:10:24 +0200 (CEST) | From | Joerg Schilling <> | Subject | Re: 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/
| |