----- Original Message -----
From: "Jens Axboe" <[EMAIL PROTECTED]>
To: "Alan Cox" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 24, 2000 9:32 PM
Subject: Re: request merge changes?
> > I have lots of raid folks bitching because they cant get nice 64K I/O's
> > from Linux which is what they all want (that or 128K I/O's). I think its
> > all related somewhere, but Im not a scsi layer guru
>
> Now I'm bitching too ;). What really annoys me right now that instead
> of getting
>
> rq sector 0 - 127, clustered
> rq sector 128 - 255, clustered
>
> for a continous 128KB write, I get
>
> rq sector 0 - 3
> rq sector 4 - 131
> rq sector 132 - 255
>
> As I want writes to be aligned on a sector boundary of my choice,
> this is broken.
If I had to take a guess, I would venture that the problem has to do
with the way that plugging was implemented. I believe that what is going on
is that read ahead isn't kicking in until after the first read request.
Thus you get a really small request for the first one, and once the block
driver notices that you are requesting consecutive blocks, read-ahead starts
to kick in and the request size starts to increase.
The other thing that I have been noticing - some people have complained
that the request size never exceeds 64K. My *guess* here is that what we
are doing is inserting the plug, requesting the sectors for an entire page
of memory, and then unplugging. This cannot be the entire explaination, as
once the device is busy and no longer accepting requests, plugging becomes
irrelevant.
For SCSI disks, the read ahead is set to 120 sectors - just a tad under
64K. For SCSI CDROM, it is set to 32 sectors - the thing I am not sure
about is whether this always refers to "sectors" of 512 bytes, or it
reflects the hardware sectorsize. Look for "read_ahead" in both sd.c and
sr.c to see where this is set.
If I could get the simulator running again, you could just step through
the kernel with gdb and see for yourself how all of this stuff interacts.
Then again, I probably have an older executable based upon a 2.3.8 kernel
which you could probably run - let me take a look tonight.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
