Re: pitiful performance of an SATA150 drive

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Wed, 1 Mar 2006 23:40:12 +0000 (GMT)
On Wed, 1 Mar 2006, Rink Springer wrote:

>> I believe that linux uses bufferring in  their 'raw' disks so that you
>> may be actually doing larger
>> reads and writes than you know.. (of course my knowledge of Linux is a
>> bit old so
>> they may have changed that)
>
> Linux 2.5+ will always queue I/O requests in PAGE_SIZE chunks (4KB on i386) 
> or less. These tiny requests will be concatinated by the disk elevator if 
> possible; for example, reading 64KB from block 0 once would result in 
> requesting 16 times 4KB, which will be translated to a single "Read 64KB 
> from block 0" request.
>
> Therefore, the PAGE_SIZE cache (also known as the buffer cache, which was 
> merged with the page cache in the 2.5 tree) does not hurt performance one 
> bit.
>
> I have no clue what FreeBSD does on this end.

On FreeBSD, the disk device nodes provide unbuffered disk access, under the 
assumption that consumers will be providing their own caching, or they 
wouldn't be using the direct disk interface.  Otherwise, applications like 
databases or userland file systems get double caching, which is a waste of 
memory.  Likewise, you won't be able to do sub-block reads or writes using the 
FreeBSD disk I/O interfaces.  In Linux, they probably still maintain the 
character vs. block distinction, in which case one may well offer significant 
caching, which will show up on micro-benchmarks that issue small I/O sizes or 
behave relatively unintelligently.  In FreeBSD, you'll want to issue dd reads 
and writes of disks in large block sizes, such as 1mb, and they'll get broken 
down into smaller sizes by the I/O layers.  I'm not sure what our maximum I/O 
size is, but I suspect it gets broken down into relatively small chunks on the 
way -- but better to use the largest you can, as the maximum I/O size will 
presumably increase over time.

Robert N M Watson
Received on Wed Mar 01 2006 - 22:35:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC