Why don't have bits the same rights as humans! (flushing to disk waiting time)
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.
Quoted 7 lines · 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.
I've found that unmounting the floppy disk flushes it immediately. What happens in your case if you unmount it?
Signature · 1 line
Ignacio Vazquez-Abrams <[email protected]>
Mount your floppy synchronous. Writes won't be buffered then.
David
Quoted 8 lines · 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.
Quoted 1 line · David Ford
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.
Signature · 6 lines
................................................................ : [email protected] : 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}...............:
Quoted 6 lines
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. :-)
Quoted 11 lines · 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! ;-)
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
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).
Quoted 55 lines · 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 4 lines
Kelsey Hudson [email protected] Software Engineer Compendium Technologies, Inc (619) 725-0771 ---------------------------------------------------------------------------
Quoted 7 lines · 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.
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.
Quoted 4 lines
[...]
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