compile directly into a .zip/.jar file?

[Jeff Higgins]

Hate to say this,

But I'm glad you did.
Today I first heard of I/O schedulers.
This is why I like following this group.

 

[Eric Sosman]

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.

 

[Arne Vajhøj]

The manpages for fflush()m and fsync() could be a little clearer, but I
read them as saying that both functions force a write to disk. The only
difference is the type of file reference argument they take: fflush()
takes a FILE* stream reference while fsync() takes an int file
description.

Linux man pages are rather clear:

<quote>
Notes
Note that fflush() only flushes the user-space buffers provided by the C
library. To ensure that the data is physically stored on disk the kernel
buffers must be flushed too, for example, with sync(2) or fsync(2).
</quote>

Arne