Re: recommendations for stripe/chunk size

["Keld Jørn Simonsen" <keld@dkuug.dk>]

On Thu, Feb 07, 2008 at 06:40:12AM +0100, Iustin Pop wrote:
> On Thu, Feb 07, 2008 at 01:31:16AM +0100, Keld Jørn Simonsen wrote:
> > Anyway, why does a SATA-II drive not deliver something like 300 MB/s?
> 
> Wait, are you talking about a *single* drive?

Yes, I was talking about a single drive.

> In that case, it seems you are confusing the interface speed (300MB/s)
> with the mechanical read speed (80MB/s).

I thought the 300 MB/S was the transfer rate between the disk and the
controllers memory in its buffers, but you indicate that this is the
speed between the controller's buffers and main RAM. 

I am, as Neil, amazed by the speeds that we get on current hardware, but
still I would like to see if we could use the hardware better.
Asyncroneous IO could be a way forward. I have written some mainframe
utilities where asyncroneous IO was the key to the performance,
so I thought that it could also become handy in the Linux kernel. 

If about 80 MB/s is the maximum we can get out of a current SATA-II
7200 rpm drive, then I think there is not much to be gained from
asyncroneous IO. 

> If you are asking why is a
> single drive limited to 80 MB/s, I guess it's a problem of mechanics.
> Even with NCQ or big readahead settings, ~80-~100 MB/s is the highest
> I've seen on 7200 RPM drives. And yes, there is no wait until the CPU
> processes the current data until the drive reads the next data; drives
> have a builtin read-ahead mechanism.
> 
> Honestly, I have 10x as many problems with the low random I/O throughput
> rather than with the (high, IMHO) sequential I/O speed.

I agree that random IO is the main factor on most server installations.
But on workstations the sequentioal IO is also important, as the only
user is sometimes waiting for the computer to respond.
And then I think that booting can benefit from faster sequential IO.
And not to forget, I think it is fun to make my hardware run faster!

best regards
Keld
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html