From owner-freebsd-current Thu Mar 23 15:42:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id 6466837BF18 for ; Thu, 23 Mar 2000 15:42:09 -0800 (PST) (envelope-from grog@mojave.worldwide.lemis.com) Received: from mojave.worldwide.lemis.com ([216.88.157.130]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id KAA02350; Fri, 24 Mar 2000 10:11:47 +1030 (CST) (envelope-from grog@mojave.worldwide.lemis.com) Received: (from grog@localhost) by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09602; Thu, 23 Mar 2000 15:41:23 -0800 (PST) (envelope-from grog) Date: Thu, 23 Mar 2000 15:41:23 -0800 From: Greg Lehey To: Matthew Dillon Cc: Wilko Bulte , Poul-Henning Kamp , Alfred Perlstein , current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <20000323154123.E9318@mojave.worldwide.lemis.com> Reply-To: Greg Lehey References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl> <200003211729.JAA81170@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200003211729.JAA81170@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Mar 21, 2000 at 09:29:56AM -0800 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 21 March 2000 at 9:29:56 -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. > > 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. I think that in the majority of cases there's no need to transfer more than requested. It could only apply to reads anyway, and the drive cache probably has this data anyway. In RAID adapters, it seems to almost always be due to poor firmware design. For regular files, it might be an idea to set a flag to indicate whether read-ahead has any hope of being useful (for example, on an ftp server the answer would be "yes"; for index-sequential files or such the answer would normally be "no". Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message