Re: poor sata performance on 2.6

[Jeff Garzik <jgarzik@pobox.com>]

Denis Vlasenko wrote:
> On Thursday 15 April 2004 17:48, Konstantin Sobolev wrote:
> 
>>On Thursday 15 April 2004 18:33, Justin Cormack wrote:
>>
>>>On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
>>>
>>>>On Thursday 15 April 2004 18:00, Justin Cormack wrote:
>>>>
>>>>>hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks,
>>>>>and Seagate from the same controller. Can you send lspci,
>>>>>/proc/interrupts and dmesg...
>>>>
>>>>Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned
>>>>off.
>>>
>>>ah. Make a filesystem on it and mount it and try again. I see you have
>>>no partition table and so probably no filesystem. This means the block
>>>size is set to default 512byte not 4k which makes disk operations slow.
>>>Any filesystem should default to block size of 4k, eg ext2.
>>
>>Very interesting!
>>created partition table,
>>kos sata # mkfs.ext2 /dev/sda1
>>[..skipped..]
>>kos mnt # cd /
>>kos / # mkdir wd
>>kos / # mount /dev/sda1 /wd
>>kos / # hdparm -t -a8192 /dev/sda
>>
>>/dev/sda:
>> setting fs readahead to 8192
>> readahead    = 8192 (on)
>> Timing buffered disk reads:   82 MB in  3.03 seconds =  27.02 MB/sec
>>
>>kos / # mount | grep sda
>>/dev/sda1 on /wd type ext2 (rw)
>>kos / # hdparm -t -a8192 /dev/sda
>>
>>/dev/sda:
>> setting fs readahead to 8192
>> readahead    = 8192 (on)
>> Timing buffered disk reads:  206 MB in  3.02 seconds =  68.15 MB/sec
>>kos / # hdparm -t -a8192 /dev/sda
>>
>>/dev/sda:
>> setting fs readahead to 8192
>> readahead    = 8192 (on)
>> Timing buffered disk reads:  206 MB in  3.02 seconds =  68.18 MB/sec
>>
>>So first time it gave the same loosy 27 MB/s and subsequent tests give
>>pretty good 68 MB/s! Why?
> 
> 
> Time to CC ide/libata/block layer folks
> 
> Jeff Garzik <jgarzik@pobox.com>
> 	libata man


It seems like the situation is already resolved, to me.

When you mount a filesystem, it changes the default block size (512 or 
1024) to the filesystem block size, normally 4096.  This would certainly 
increase the throughput.

	Jeff