This is a known problem with "df" - it does a "sync()" for no real
reason. Now, the fact that it affects you even when reading from a floppy
is surprising, but the real problem is the "sync()" (umm, thinking about
it the sync probably waits for _all_ blocked buffers, whether they are
blocked for reading or for writing).
Now, we haven't really bothered to make "sync()" very clever, because
it's not meant to be clever, it's just meant to sync the disks (read that
as "if you use sync(), it's your problem").
Now, the reason "df" does a sync() call is that way back in the year 5 BC
or so, that was what you were supposed to do to flush out the filesystem
buffers to disk, so that the df program then could go and read the disk
information directly (!) from the superblocks.
Now, that obviously doesn't work with any reasonably new unix (like
anything that has been updated in the last 15 years or so), because we
have different filesystems and some of them are actually over the network
etc. So these days df just does a "statfs()" call to get the information
from the kernel.
For some strange reason the df people left the sync in there, probably on the
assumption that if you want to know how much disk you have free, you probably
also want to wait a few minutes until all of your multi-megabyte buffer
cache has been written out to disk.
[ Yes, I'm being ironic ].
In short, the real answer is to recompile "df" with the sync call
commented out. You might want to send a "misfeature-report" to whoever
maintains fileutils (or whwrever df is found, I'm too lazy to check).
The linux "sync()" behaviour might be considered strange, but at least it
isn't stupid and unreasonable (it actually waits for all IO to complete,
and it actually does this _synchronously_, because there really isn't any
other reason to call sync() than that these days).
Linus