Date: Fri, 05 Jan 2007 10:18:24 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: lulf@stud.ntnu.no Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Pluggable Disk Schedulers in GEOM Message-ID: <3763.1167992304@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 05 Jan 2007 01:58:00 %2B0100." <20070105015800.s3rqdzgm8k8owk4s@webmail.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3763.1167992304>