fsync and speed

[Andrew Tridgell]

Recently some people have been asking about the speed of copying large
files. In my experience the main cause of _really_ bad throughput is
the common that many Windows application programmers don't know the
difference between sync and flush.

This was confirmed when JohnT rang me a few minutes ago to ask why a
copy of a 44MB file from explorer in Win98 took over 30 minutes to a
Samba server. I logged in and did a "strace -ttp pid" and found that
over 90% of the time was being spent in fsync(). Adding 
"#define NO_FSYNC 1" in local.h reduced the time to under 2 minutes.
It didn't get faster than that because the stupid client was writing
the data in 1.5k chunks.

So, shall we add an option "no sync = yes/no" to go aong with our
current "always sync = yes/no" ? Those fsync calls are generated
because the stupid client programmer decided to call sync on every
write to the file. He probably wanted flush but didn't understand the
difference. sync is _very_ expensive whereas flush is cheap. sync is
pointless unless you are writing a transaction system. sync only ever
makes a difference if the server crashes (ie. the OS crashes, not just
the process).

We've put up with this for a long time by saying that we are doing the
right thing by the protocol spec. The problem is that with the Win98
explorer calling sync on every 1.5k write the Samba performance is now
really dreadful. I think we need a "no sync" option to combat this
stupid MS programming. Anyone disagree? Anyone like to make it the
default? 

       - Tridge