Date: Wed, 1 Mar 2006 23:40:12 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Rink Springer <rink@il.fontys.nl> Cc: sos@freebsd.org, "Mikhail T." <mi@aldan.algebra.com>, Julian Elischer <julian@elischer.org>, Brian Candler <B.Candler@pobox.com>, current@freebsd.org Subject: Re: pitiful performance of an SATA150 drive Message-ID: <20060301233705.Y54541@fledge.watson.org> In-Reply-To: <20060301205707.GA65200@il.fontys.nl> References: <200603010505.k2155HfQ003205@aldan.algebra.com> <20060301144124.GA14411@uk.tiscali.com> <4405EFE9.6030807@elischer.org> <20060301205707.GA65200@il.fontys.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060301233705.Y54541>