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

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-24 20:21 +0000
Organization	UK Free Software Network
Message-ID	<ji8rgu$s68$1@localhost.localdomain> (permalink)
References	(4 earlier) <ji3q44$le1$1@news.albasani.net> <ji44tm$j5o$3@localhost.localdomain> <4f45a713$0$291$14726298@news.sunsite.dk> <ji6hcc$8j1$3@localhost.localdomain> <dKmdnbUGUZqfudrSnZ2dnUVZ_g6dnZ2d@earthlink.com>

Show all headers | View raw

On Thu, 23 Feb 2012 21:45:33 -0800, Patricia Shanahan wrote:

> On 2/23/2012 3:16 PM, Martin Gregorie wrote:
>> On Wed, 22 Feb 2012 21:40:19 -0500, Arne Vajhøj wrote:
>>
>>
>>> Most OS'es support async IO.
>>>
>> Yes, I know, but its not relevant to a single-threaded process since
>> its logic generally requires it to wait for a read or write to complete
>> before it continues[1]. Hence my comment that this prevents head
>> movement being optimized unless a lot of processes are active because
>> there's only one outstanding IOP per process.
>>
>> [1] unless you're deliberately doing async i/o using poll() or
>>      select() (in C) or nio (in Java), in which case the process is
>>      often best regarded as a half-way house between single and
>>      multi-threaded logic.
>>
>>
>>
> There are some exceptions to this. For example, if you are reading a
> file sequentially, the OS may prefetch blocks you have not yet
> requested, and have multiple reads outstanding as a result.
>
Fair point, and I've seen blinding speed from reads where the disk 
drivers used track reads, but it still doesn't affect my point that 
there's still only one I/O request in the queue per active single 
threaded process. Head movement optimisation is simply sidestepped in 
this case.

> Depending on the OS and how the IO is being handled, a write may appear
> to be complete from the program's point of view once the data has been
> copied to a kernel buffer. The OS may be writing out modified blocks,
> including swap space blocks, at any time.
> 
Again agreed: its fair to regard a write as complete from the program's 
POV as soon as it can reread the block/record - something that many 
indexed sequential access schemes need to do to re-establish a 'current 
record' pointer.


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