[luau] improving sustainable write to disk rates

[Charles Lockhart]

cpaul at telemetrybox.org wrote:

>>Can anybody recommend ways of improving write to disk performance under
>>Linux?  I've got a system with dual scsi drives attatched via RAID
>>controller set to level 0 (striping), and am getting what I consider to be
>>pretty low long term data rates for what should be a high performance
>>system.
>>    
>>
>
>Couple of questions:
>  o What blocksize are you writing with?
>
"cat partitions" reports 35,553,120 blocks, doesn't say how big, but the 
combined weight of the two drives is about 38GB.
calling "bstest", a junk program I wrote that calls statfs and prints 
the results,  reports that I've got 7,558,992 blocks, and that the block 
size is 4k (note, somewhere in the man page I think it says this is the 
"optimal" block size, so maybe that's different than the "real" block 
size...).   This would work out to be about right for the size of the 
partition the filesystem is on.

I'm gonna guess that the block size is 4k.  Correct away.

>  o Are you using buffered i/o?
>
yeah.

>  o Are you writing to the device at the block level, or with a filesystem?
>  o Which filesystem?
>
yeppers, and I think it's ext3

>  o Have you tested the i/o of this device with dd?
>	 (For those of you who are new to dd:
>     `dd if=/dev/zero of=/mnt/array0/zeroes bs=1M count=500`
>	 will write 500 megs of zeros to the file 'zeroes', adjusting the
>	 blocksize (bs=) and the count (count=) is a good way of benchmarking
>	 device performance)
>
no, but I'll try it, and yes, new to dd.

>  o Is this the same problem you were having last year?  <eg>
>
no, but similar system, same hardware.  Earlier this year I was (and 
really still am) having problems with what I think are contention issues 
in the hardware between disk writes and a serial fiber card that we use. 
 I have the ugliest and most unreliable looking kludge I ever wrote, but 
it seems to work, most of the time.  What I need is a real-time os 
(which I'm working on) and real-time hardware (which I'll never get).

>Aloha,
>charles
>
Thanks,

-(the other) Charles