Date: Tue, 21 Mar 2000 20:04:38 +0100 From: Wilko Bulte <wilko@yedi.iaf.nl> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, current@freebsd.org Subject: Re: patches for test / review Message-ID: <20000321200438.F966@yedi.iaf.nl> In-Reply-To: <200003211729.JAA81170@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Mar 21, 2000 at 09:29:56AM -0800 References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl> <200003211729.JAA81170@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote: > :> > :> I would think that track-caches and intelligent drives would gain > :> much if not more of what clustering was designed to do gain. > : > :Hm. But I'd think that even with modern drives a smaller number of bigger > :I/Os is preferable over lots of very small I/Os. Or have I missed the point? > As long as you do not blow away the drive's cache with your big I/O's, > and as long as you actually use all the returned data, it's definitely > more efficient to issue larger I/O's. Prefetching data that is never used is obviously a waste. 256K might be a bit big, I was thinking of something like 64-128Kb Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. I happen to hate write-caching on disk drives so I did not consider that as a factor. > If you generate requests that are too large - say over 1/4 the size of > the drive's cache, the drive will not be able to optimize parallel > requests as well. True. -- Wilko Bulte Arnhem, The Netherlands http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000321200438.F966>