Date: Thu, 23 Mar 2000 15:41:23 -0800 From: Greg Lehey <grog@lemis.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Wilko Bulte <wilko@yedi.iaf.nl>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <20000323154123.E9318@mojave.worldwide.lemis.com> 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000323154123.E9318>