Why don't have bits the same rights as humans! (flushing to disk waiting time)

Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Otto Wyss]

I recently wrote some small files to the floppy disk and noticed almost nothing
happened immediately but after a certain time the floppy actually started
writing. So this action took more than 30 seconds instead just a few. This
remembered me of the elevator problem in the kernel. To transfer this example
into real live: A person who wants to take the elevator has to wait 8 hours
before the elevator even starts. While probably everyone agrees this is
ridiculous in real live astonishingly nobody complains about it in case of a disk.

Why don't have bits the same rights as humans! ;-) 

I know this waiting period should help the elevator algorithm to choose a better
service. But is this really true? Lets assume the following situations:

1. Just a few persons/time period wants to use the elevator. The elevator just
service each person since no other is waiting for its service.

2. A rather lot of persons/time period wants to use the elevator, of course the
elevator can't now service all immediately. But now since accumulation starts
the elevator can improve its service which of course reduces the accumulation
which decreases its service and so on.

3. More persons/time period than the elevator can service wants to use it, the
accumulation always gets higher. Now the elevator works as if it has been given
a large accumulation time. Hopefully this situations doesn't persist or the
system itself gets broke.

Now of course a waiting time helps to push the elevator service into situation 3
even if service request are still in situation 2 or 1. Also real elevators have
this waiting time, it's starts when the first person enters and choose his
destination until it has missed the next person (either direction or already
passed). A rough estimate gives a waiting time in the range of about an average
service time.

If I assume an average service time for bits (disk access) of about 10ms around
3000 service requests could be accumulated before any service starts. Now I dare
to question that even the best elevator algorithm is able to optimize more than
20 service requests on a usefull base, so any waiting time above 200ms is simply useless.

Lets go back to situation 2. As we see accumulation happens on a "natural" way
which imposes a certain waiting time. I guess this alone gives a service which
is at least as good as halve of the best service.

Could anybody produce any real figures to prove/disprove my theory? Could
anybody benchmark the disk access for the 3 waiting times (0, 200ms 30sec) with
different loads?

O. Wyss

Please CC, thanks.

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Ignacio Vazquez-Abrams]

On Sun, 19 Aug 2001, Otto Wyss wrote:

> I recently wrote some small files to the floppy disk and noticed almost nothing
> happened immediately but after a certain time the floppy actually started
> writing. So this action took more than 30 seconds instead just a few. This
> remembered me of the elevator problem in the kernel. To transfer this example
> into real live: A person who wants to take the elevator has to wait 8 hours
> before the elevator even starts. While probably everyone agrees this is
> ridiculous in real live astonishingly nobody complains about it in case of a disk.

I've found that unmounting the floppy disk flushes it immediately. What
happens in your case if you unmount it?

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[David Ford]

Mount your floppy synchronous.  Writes won't be buffered then.

David

Otto Wyss wrote:

>I recently wrote some small files to the floppy disk and noticed almost nothing
>happened immediately but after a certain time the floppy actually started
>writing. So this action took more than 30 seconds instead just a few. This
>remembered me of the elevator problem in the kernel. To transfer this example
>into real live: A person who wants to take the elevator has to wait 8 hours
>before the elevator even starts. While probably everyone agrees this is
>ridiculous in real live astonishingly nobody complains about it in case of a disk.
>

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Jakob Østergaard]

On Sun, Aug 19, 2001 at 06:16:13PM -0400, David Ford wrote:
> Mount your floppy synchronous.  Writes won't be buffered then.

Or use tar on /dev/fd0

Seriously - many people are not aware of that since they think of floppies
like filesystems.  But for many purposes tar is exactly what you want - and
then there's no mounting and un-mounting, no buffered writes, and it may
even work directly in your HP-UX box too    :)

If you absolutely must write to a FAT filesystem on the floppy, you can
use the mtools package (mcopy, mdir, mformat, ...) - again, you won't have to
mount or unmount, writes are not buffered, etc. etc.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Kip Macy]

> If you absolutely must write to a FAT filesystem on the floppy, you can
> use the mtools package (mcopy, mdir, mformat, ...) - again, you won't have to
> mount or unmount, writes are not buffered, etc. etc.

Or just type sync. :-)

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Helge Hafting]

Otto Wyss wrote:
> 
> I recently wrote some small files to the floppy disk and noticed almost nothing
> happened immediately but after a certain time the floppy actually started
> writing. So this action took more than 30 seconds instead just a few. This
> remembered me of the elevator problem in the kernel. To transfer this example
> into real live: A person who wants to take the elevator has to wait 8 hours
> before the elevator even starts. While probably everyone agrees this is
> ridiculous in real live astonishingly nobody complains about it in case of a disk.
> 
> Why don't have bits the same rights as humans! ;-)
> 
Bits are in no hurry.  If you want to eject - run umount.  umount
will flush everything immediately.  If you merely want stuff out to
disk - use sync.

Putting writes on hold for a while helps the impossible to foresee
situation when some important reads suddenly comes up.  The system don't
_know_ yet it will happen, but it will happen in shorter time than
it takes to write the stuff.  So writes are stalled in cache because
you have enough of that, and it is always possible to cache a write.
Reads must be done now and then because they aren't always in cache,
and the kernel tries to keep devices ready to do that on short notice.


Helge Hafting

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Dr. Kelsey Hudson]

It sounds like your files are getting cached to memory before the pages
are flushed to disk. If you want them flushed instantly after you do a
write, simply do a 'sync' after the write or mount the filesystem
synchronous (ie nothing is cached, ever).


On Sun, 19 Aug 2001, Otto Wyss wrote:

> I recently wrote some small files to the floppy disk and noticed almost nothing
> happened immediately but after a certain time the floppy actually started
> writing. So this action took more than 30 seconds instead just a few. This
> remembered me of the elevator problem in the kernel. To transfer this example
> into real live: A person who wants to take the elevator has to wait 8 hours
> before the elevator even starts. While probably everyone agrees this is
> ridiculous in real live astonishingly nobody complains about it in case of a disk.
>
> Why don't have bits the same rights as humans! ;-)
>
> I know this waiting period should help the elevator algorithm to choose a better
> service. But is this really true? Lets assume the following situations:
>
> 1. Just a few persons/time period wants to use the elevator. The elevator just
> service each person since no other is waiting for its service.
>
> 2. A rather lot of persons/time period wants to use the elevator, of course the
> elevator can't now service all immediately. But now since accumulation starts
> the elevator can improve its service which of course reduces the accumulation
> which decreases its service and so on.
>
> 3. More persons/time period than the elevator can service wants to use it, the
> accumulation always gets higher. Now the elevator works as if it has been given
> a large accumulation time. Hopefully this situations doesn't persist or the
> system itself gets broke.
>
> Now of course a waiting time helps to push the elevator service into situation 3
> even if service request are still in situation 2 or 1. Also real elevators have
> this waiting time, it's starts when the first person enters and choose his
> destination until it has missed the next person (either direction or already
> passed). A rough estimate gives a waiting time in the range of about an average
> service time.
>
> If I assume an average service time for bits (disk access) of about 10ms around
> 3000 service requests could be accumulated before any service starts. Now I dare
> to question that even the best elevator algorithm is able to optimize more than
> 20 service requests on a usefull base, so any waiting time above 200ms is simply useless.
>
> Lets go back to situation 2. As we see accumulation happens on a "natural" way
> which imposes a certain waiting time. I guess this alone gives a service which
> is at least as good as halve of the best service.
>
> Could anybody produce any real figures to prove/disprove my theory? Could
> anybody benchmark the disk access for the 3 waiting times (0, 200ms 30sec) with
> different loads?
>
> O. Wyss
>
> Please CC, thanks.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: Why don't have bits the same rights as humans! (flushing to disk waiting time)

[Daniel Phillips]

On August 19, 2001 11:11 pm, Otto Wyss wrote:
> I recently wrote some small files to the floppy disk and noticed almost nothing
> happened immediately but after a certain time the floppy actually started
> writing. So this action took more than 30 seconds instead just a few. This
> remembered me of the elevator problem in the kernel. To transfer this example
> into real live: A person who wants to take the elevator has to wait 8 hours
> before the elevator even starts. While probably everyone agrees this is
> ridiculous in real live astonishingly nobody complains about it in case of a disk.

My early flush patch, posted a month or so ago, takes care of this nicely.
I'm just waiting for 2.5 to roll around to do some more work on it.

> [...]
> Could anybody produce any real figures to prove/disprove my theory? Could
> anybody benchmark the disk access for the 3 waiting times (0, 200ms 30sec) with
> different loads?

Your theory is correct.  I implemented the idea, took measurements, and found
dramatic performance improvements under some loads, while getting worse on
none.  You can search lwn.net for a nice writeup by Jonathan Corbett.

--
Daniel