From owner-freebsd-current@FreeBSD.ORG Fri Jan 5 10:18:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26DAA16A416; Fri, 5 Jan 2007 10:18:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DA2C013C468; Fri, 5 Jan 2007 10:18:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 553951747B; Fri, 5 Jan 2007 10:18:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l05AIO6U003764; Fri, 5 Jan 2007 10:18:24 GMT (envelope-from phk@critter.freebsd.dk) To: lulf@stud.ntnu.no From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 05 Jan 2007 01:58:00 +0100." <20070105015800.s3rqdzgm8k8owk4s@webmail.ntnu.no> Date: Fri, 05 Jan 2007 10:18:24 +0000 Message-ID: <3763.1167992304@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Pluggable Disk Schedulers in GEOM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 10:18:29 -0000 In message <20070105015800.s3rqdzgm8k8owk4s@webmail.ntnu.no>, lulf@stud.ntnu.no writes: >I was wondering if someone have started on the pluggable >disk-scheduler project >on the "new ideas"-page yet. > >I was thinking on how one could implement this in GEOM by [...] Sorting and scheduling should only be implemented at selected points in the GEOM mesh and it can even be argued that it should only be implemented at the bottom most level, right above the physical storage media. But given the increasing intelligence of disk drives in this area, I would also caution against expecting too much of a gain in reality. So before you embark on a major expedition, I would suggest that you do some benchmarking and experiments with the current disksorting, to shed light on the potential for improvement. Here are some ideas: Remove disksorting and see if if and how big a difference it makes today. Test both SCSI, ATA and USB media, and test both low-level benchmarks and "real-world" workloads. Change disksorting to reverse unidirectional elevator and bidirectional elevator and see if it makes a difference. (Modern disks store blocks in reverse sector order on the disk, discover and explain why) Capture an I/O trace from a suitably sensible realworld system, including the detailed timestamps of issuance and completion of the requests. Treat results statistically and try to determine a formula for predicting how long a given request is going to take for the disk. It's not that I think that all your ideas are bad, I am just not sure that the (traditional) view of the hardware they are based on, is still relevant, and I think your time would be much better spent addressing that question. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.