Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


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

Re: O.T. optimising file placement

From Lew <noone@lewscanon.com>
Newsgroups comp.lang.java.programmer
Subject Re: O.T. optimising file placement
Date 2012-02-22 14:27 -0800
Organization albasani.net
Message-ID <ji3q44$le1$1@news.albasani.net> (permalink)
References <3gm7k7lgroqn30g0nd7lqgsqo60hq02em1@4ax.com> <ji1kln$k5a$1@dont-email.me> <ji1qjm$drr$1@dont-email.me> <f6fak7d0tf9tva9lqh0jtd6imjgm8u5oa3@4ax.com>

Show all headers | View raw


On 02/22/2012 11:15 AM, Roedy Green wrote:
> On Tue, 21 Feb 2012 23:23:14 -0500, Jeff Higgins
> <jeff@invalid.invalid>  wrote, quoted or indirectly quoted someone who
> said :
>
>> <http://en.wikipedia.org/wiki/Hybrid_drive>
>
> Back before the Internet, I was pushing for what I call "Marthaing"
> drives. We might get them any year now.  The idea is a microprocessor
> inside the hard disk in the background keeps reordering the tracks so
> that the most frequently used ones are near the outer rim.

That won't help much.

> It would have a delayed write cache built in.  Today it would be
> easier to implement since you could use a  non-volatile fast SSD to
> store the map of logical to physical track numbers and a fat delayed
> write. In the background the disk moves infrequently used tracks from
> the outer rim toward the center in order to free up slots for writing.
>
> People are willing to pay double or triple for 7200 RPM to 10,000 RPM.
> With that sort of budget, used instead for internal cleverness, RAM
> and SSD you might be able to get considerably better performance.

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. 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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Back to comp.lang.java.programmer | Previous | NextPrevious 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