Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: O.T. optimising file placement Date: Thu, 23 Feb 2012 01:31:34 +0000 (UTC) Organization: UK Free Software Network Lines: 45 Message-ID: References: <3gm7k7lgroqn30g0nd7lqgsqo60hq02em1@4ax.com> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1329960694 19640 84.45.235.129 (23 Feb 2012 01:31:34 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Thu, 23 Feb 2012 01:31:34 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12262 On Wed, 22 Feb 2012 14:27:17 -0800, Lew wrote: > Modern hard drives, pretty much all of them, have a buffer and > microprocessor as part of the hardware. We're not going to get any > "Marthaing" as you describe it (wherever the heck /that/ term came from) > because what they're already doing is already so effective. > > What they mostly do is collect read and write requests and combine them > in elevator-seek order, along with full-track readahead. This optimizes > disk access for single sweeps of the drive heads. > Agreed, and a mainframe OS I was using in the early '70s (ICL's George 3) was doing it back then and very effective it is too for speeding up disk access. Back in the day it pushed the speed of the 2800 rpm, 60 MB washing-machine sized disk drives up from around 8 accesses/sec to something like 20-30 per sec. However, its ineffective unless there are many active processes simultaneously requesting disk i/o. If all the requests come from one single threaded process then it can't optimize head movement because there's never more than one pending request at a time. I know this is reduction ad absurdam, but it does make the point that a small active process population is unlikely to be optimised as well as a large one. This is relevant today for allmost all single-user workstations regardless of whether they are running Windows, Linux or OS X. Since the majority of applications run on these machines are single threaded, about the only time you have more than one process accessing the disk is when the user is hammering away at a task, be it wordprocessing, spread-sheet, browser or IDE and the mail reader, sitting in the background, finds some mail waiting. > The on-drive buffer > also holds enough data for most reads and writes, overtaking any > advantage that any (perforce extremely slow) physical re-ordering of the > tracks could accomplish. > Yep, the on-drive buffer will almost always be capable of holding several physical tracks and, in addition, on a *NIX system anyway, all RAM not occupied by running processes and their data will contain disk buffers. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |