Fsync is no longer synchronous
Alain KNAFF (Alain.Knaff@imag.fr)
Thu, 17 Oct 1996 11:50:49 +0200
It seems that in recent kernels (at least 2.1.3 and 2.1.4, but
possibly earlyer) the fsync syscall is no longer synchronous. I.e. it
may schedule the flushing of the data to the disk, but return before
the flushing is actually complete. Synchronous syncing is needed for
reliable operations on removeable media (such as floppy disks). And
what's worse, asynchronous syncs may lead to rather dramatic floppy
driver crashes if the right circumstances are met. Indeed, in order
to allow sharing the floppy controller with ftape, the floppy driver
relinquishes its hardware resources (DMA and IRQ) when no one holds an
open descriptor to a floppy device (for this purpose, mounting and
swapon also count as open). Before relinquishing these resources, it
calls block_fsync (equivalent to user-level fsync) to sync all buffers
to disk. This is needed for 3 reasons:
1. To make sure that all data is written on application exit. (So
that the user can assume that when mcopy has returned, the copy has
been physically done.)
2. To make sure no I/O happens when all resources are released
while no floppy device is open.
3. To make sure no I/O happens after the floppy module has been removed
from the kernel.
With an unreliable block_fsync call, neither of these goals are
fulfilled:
1. Removing the disk immediately after mcopy exits may lead to
uncopied data.
2. When the dirty floppy buffers are eventually flushed by the buffer
cache layer, the floppy driver crashes, because it is no longer in a
state where it can accept requests, or worse, because the module no
longer exists.
Alain