Date: Tue, 21 Mar 2000 09:29:56 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Wilko Bulte <wilko@yedi.iaf.nl> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <200003211729.JAA81170@apollo.backplane.com> References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :> 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? : :-- :Wilko Bulte Arnhem, The Netherlands :http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org 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. 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. -Matt Matthew Dillon <dillon@backplane.com> 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?200003211729.JAA81170>