Re: IDE/ATAPI in 2.5

[Joerg Schilling]

>From [e-mail] Sun Jul 14 17:05:31 2002

>>>I will violently oppose anything that implies that the IDE layer uses the
>>>SCSI layer normally.  No way, Jose. I'm all for scrapping, but the thing
>>>that should be scrapped is ide-scsi.
>> 
>> Nobody who has a technical backgroupd and knows what to do wuld ever
>> make such a proposal.
>> 
>> Instead, there needs to be one or more SCSI HA driver as part of the
>> SCSI stack. This driver also needs to deal with plain ATA in order
>> to be able to coordinate access.
>> 
>> Jörg

>Such driver would only work with ATAPI devices. Joerg, does not
>seem to realize that the vast majority of IDE devices do not
>support ATAPI at all. As a rule of thumb, winchesters do not,
>CD-ROMs and such do, and tapes do too. To make a pseudo-HA
>driver which speaks plain IDE and plugs into SCSI subsistem
>would saddle the IDE with SCSI limitations, and add one more
>layer for no benefit whatsoever.

You did not seem to read my previous postings. It is simple to have
a second upper level interface for the IDE HBS driver that connects to
e.g. the ATA HD driver interface. If you like to have 100% backwards
compatibility you could even put the current non-standard part from 
ide-cd on top of this 2nd type of upper level code. Make sure, that 
the ATAPI/SCSI part is probed first, to allow to connect the SCSI 
drivers first and lock the ATA type interface against being used by
drivers like ide-cd in case that a SCSI type of high level driver did
feel responsible to deal with a specific drive.

Of curse this will only work if there is some kind of accepted 
development leadership that makes a concept, works on data structures and 
finally instructs the maintainers of old code to find a way to convert
their current driver to the new model. This new model usually would
cause parts of the code that exists more than once to be removed from
all the old drivers that have been considered to represent 'the wrong way'
in the tree of the evolution of the kernel.

Stop looking at your own belly and have a look at what other OS do.
It seems to be one of the main problems in the Linux development.

People usually only look at Linux and inside Linux, they only look at 
their part of the kernel. Doing it this way, they define their own 
interfaces and don't look enough to the left and to the right.

To make it not look as if I am only bashing current IDE/SCSI code, let
me give an example from the filesystem part.

Have a look at the file 

ftp://ftp.fokus.gmd.de/pub/unix/star/testscript/rock.tar.bz2

It is a tar archive that contains 207,440 empty files and one directory 
using the names of the files in the 'rock' subdirectory from the 
freedb project. This is a snapshot taken on May 30th 2002.

If you extract this archive on a machine running Solaris or FreeBSD,
it takes less than 7 minutes.

A pentium 800 running Solaris 9 results in:

# star -xp -time < rock.tar.bz2
star: WARNING: Archive is bzip2 compressed, trying to use the -bz option.
star: 10372 blocks + 1536 bytes (total of 106210816 bytes = 103721.50k).
star: Total time 405.988sec (255 kBytes/sec)
6:46.051r 12.920u 63.420s 18% 0M 0+0k 0st 0+0io 0pf+0w

You see during the 6:43, the machine is 82% idle.

A Pentium 1200 running Linux-2.5.25 (ext3) results in:

# star -xp -time < rock.tar.bz2
star: WARNING: Archive is bzip2 compressed, trying to use the -bz option.
star: 10372 blocks + 1536 bytes (total of 106210816 bytes = 103721.50k).
star: Total time 3190.483sec (32 kBytes/sec)
53:10.490r 12.299u 2970.099s 93% 0M 0+0k 0st 0+0io 4411pf+0w

You see, during the 53:20, the machine is only 7% idle!

It wasted 2900 seconds of CPU time on Linux. Let me guess: this was done
inside the function strcmp().

There are ~ 5 different filesystems on Linux, but none if the projects seem
to care about the code outside the FS low level code. I suspect, that
this is not any better if you use reiserfs.

Solaris and FreeBSD put all the effort into one filesystem trying to make
it as good as possible. In Linux, it seems that nobody prooved the overall
concept of the kernel.

Jörg

 EMail:[e-mail] (home) Jörg Schilling D-13353 Berlin
       [e-mail]		(uni)  If you don't have iso-8859-1
       [e-mail]		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix