Groups > comp.lang.java.programmer > #12262

Re: O.T. optimising file placement

From	Martin Gregorie <martin@address-in-sig.invalid>
Newsgroups	comp.lang.java.programmer
Subject	Re: O.T. optimising file placement
Date	2012-02-23 01:31 +0000
Organization	UK Free Software Network
Message-ID	<ji44tm$j5o$3@localhost.localdomain> (permalink)
References	<3gm7k7lgroqn30g0nd7lqgsqo60hq02em1@4ax.com> <ji1kln$k5a$1@dont-email.me> <ji1qjm$drr$1@dont-email.me> <f6fak7d0tf9tva9lqh0jtd6imjgm8u5oa3@4ax.com> <ji3q44$le1$1@news.albasani.net>

Show all headers | View raw

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       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

O.T. optimising file placement Roedy Green <see_website@mindprod.com.invalid> - 2012-02-21 09:59 -0800
  Re: O.T. optimising file placement Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-21 18:05 -0800
  Re: O.T. optimising file placement Jeff Higgins <jeff@invalid.invalid> - 2012-02-21 21:41 -0500
    Re: O.T. optimising file placement Jeff Higgins <jeff@invalid.invalid> - 2012-02-21 23:23 -0500
      Re: O.T. optimising file placement Roedy Green <see_website@mindprod.com.invalid> - 2012-02-22 11:15 -0800
        Re: O.T. optimising file placement Jeff Higgins <jeff@invalid.invalid> - 2012-02-22 16:00 -0500
          Re: O.T. optimising file placement Jeff Higgins <jeff@invalid.invalid> - 2012-02-22 16:03 -0500
            Re: O.T. optimising file placement Gene Wirchenko <genew@ocis.net> - 2012-02-22 14:52 -0800
              Re: O.T. optimising file placement Jeff Higgins <jeff@invalid.invalid> - 2012-02-22 18:24 -0500
                Re: O.T. optimising file placement Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-22 17:10 -0800
                Re: O.T. optimising file placement Gene Wirchenko <genew@ocis.net> - 2012-02-22 20:02 -0800
        Re: O.T. optimising file placement Lew <noone@lewscanon.com> - 2012-02-22 14:27 -0800
          Re: O.T. optimising file placement Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-23 01:31 +0000
            Re: O.T. optimising file placement Arne Vajhøj <arne@vajhoej.dk> - 2012-02-22 21:40 -0500
              Re: O.T. optimising file placement Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-23 23:16 +0000
                Re: O.T. optimising file placement Patricia Shanahan <pats@acm.org> - 2012-02-23 16:22 -0800
                Re: O.T. optimising file placement Patricia Shanahan <pats@acm.org> - 2012-02-23 21:45 -0800
                Re: O.T. optimising file placement Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-24 20:21 +0000
                Re: O.T. optimising file placement Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 20:31 -0500
                Re: O.T. optimising file placement Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-25 13:15 +0000
            Re: O.T. optimising file placement Lew <noone@lewscanon.com> - 2012-02-23 16:39 -0800
              Re: O.T. optimising file placement Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-24 01:49 +0000
                Re: O.T. optimising file placement Lew <noone@lewscanon.com> - 2012-02-24 10:50 -0800
                Re: O.T. optimising file placement Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-24 23:59 +0000
              Re: O.T. optimising file placement Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 20:25 -0500
    Re: O.T. optimising file placement Roedy Green <see_website@mindprod.com.invalid> - 2012-02-22 10:54 -0800

csiph-web