Bug#3157: df from fileutils calls sync() needlessly

[and1000@cam.ac.uk (Austin Donnelly)]

In article
<Pine.LNX.3.91.960530151805.29439A-100000@linux.cs.Helsinki.FI>
Linus Torvalds writes:
>
>On Thu, 30 May 1996, Johnny Stenback wrote:
>>
>> I noticed a strange thing in my linux 1.99.8 PC (Pentium) yesterday, I
>> made a backup copy of some floppyes with 'dd if=/dev/fd0 of=...'  and
>> while dd was reading my floppy I wanted to check if there was enough
>> space left for a couple of floppyes on the partition wher I wrote
>> them, the when I wrote 'df' the df process hung and did nothing (^C or
>> ^Z didn't work) until the dd process was done.
>
>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


I've also noticed this behaviour.

I include a patch to solve this:

------------------------------------------------------------
--- df.c.old	Thu May 30 20:01:30 1996
+++ df.c	Thu May 30 20:04:31 1996
@@ -85,7 +85,7 @@
    difference on some systems -- SunOs4.1.3, for one.  I have been assured
    that it is *not* necessary on Linux, so there should be a way to
    configure this.  FIXME.  */
-static int require_sync = 1;
+static int require_sync = 0;

 /* Nonzero if errors have occurred. */
 static int exit_status;
------------------------------------------------------------

This changes the default for the undocumented command line option to
change whether a sync is done or not.

Austin