Path: csiph.com!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: compile directly into a .zip/.jar file?
Date: Wed, 16 Apr 2014 16:20:19 -0400
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <limom6$8ps$1@dont-email.me>
References: <slrnlkicek.bi9.avl@login.logic.tuwien.ac.at>	<1l96oa6aew63h$.1wt64t9w3vv91.dlg@40tude.net>	<534ad197$0$301$14726298@news.sunsite.dk>	<slrnlkm59e.bi9.avl@login.logic.tuwien.ac.at>	<534c8e5e$0$297$14726298@news.sunsite.dk> <lija0u$bte$1@dont-email.me>	<534dc817$0$300$14726298@news.sunsite.dk> <lilt41$mth$1@dont-email.me>	<lim623$nug$1@dont-email.me> <limcb0$924$1@dont-email.me> <limluk$h08$3@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 16 Apr 2014 20:20:22 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="9020"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19hVZqPnHziO1gKBT94tl9a"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
In-Reply-To: <limluk$h08$3@dont-email.me>
Cancel-Lock: sha1:I4FPdU451i+0e75tD5u9gaifELk=
Xref: csiph.com comp.lang.java.programmer:28110

On 4/16/2014 3:33 PM, Martin Gregorie wrote:
> On Wed, 16 Apr 2014 12:45:54 -0400, Jeff Higgins wrote:
>
>> On 04/16/2014 10:58 AM, Jeff Higgins wrote:
>>
>>> as an adjunct to the manpages
>> Schedule this. A memento for me.
>> Kernel Korner - I/O Schedulers - Robert Love
>> <http://www.linuxjournal.com/article/6931>
>
> Hate to say this, but I was using a a box with a scheduler that was at
> least as good as the Anticipatory Scheduler way back in 1972 on an ICL
> 1903S mainframe running the George 3 Mk 6 OS.
>
> George 3 used a similar directory structure to Unix/Linux. Its i/o
> scheduler was, however, quite a bit different. This maintained two i/o
> queues and a vector for each disk. The vector kept book on where the
> heads were and which direction they were travelling. One of the queues
> held requests for blocks that were 'in front' of the heads and the other
> queue held requests for blocks 'behind' the heads. Both queues were
> sorted. When the 'in front' queue was empty, the queues were swapped and
> the vector reversed, so in practise the heads floated smoothly back and
> forth across the disk while sounding like castenet dancer on speed and
> the i/o rate was much higher than earlier versions, without the i/o
> scheduler, or the manual UDAS executive could manage.
> [...]

     An issue (not necessarily "problem") with this approach is that
the tracks near the inner and outer extremes get fewer/slower accesses
than those near the middle.[*]  That could be turned to advantage,
by allocating frequently-used files in the favored area and relegating
less-used material to the frozen fringes -- but then you're sort of
back in the days of fixed (usually manual) allocations.

     [*] I once heard an instructor explain it this way: He asked us
to think of three friends sitting on a bench, passing a can of beer
back and forth.  Friend A on one end takes a swig and hands the can
to B in the middle, who takes a swig and hands it on to C on the
other end, who takes his swig and hands the can -- to whom?  To his
only neighbor, B.  The swigging sequence is ABCBABCBAB... with B
getting half the beer while A and C split the rest.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid