From owner-freebsd-current Tue Mar 21 9:30:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 47E1037BC0E for ; Tue, 21 Mar 2000 09:30:06 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA81170; Tue, 21 Mar 2000 09:29:56 -0800 (PST) (envelope-from dillon) Date: Tue, 21 Mar 2000 09:29:56 -0800 (PST) From: Matthew Dillon Message-Id: <200003211729.JAA81170@apollo.backplane.com> To: Wilko Bulte Cc: Poul-Henning Kamp , Alfred Perlstein , current@FreeBSD.ORG Subject: Re: patches for test / review References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message