Messages in this thread |  | | Subject | Fsync is no longer synchronous | Date | Thu, 17 Oct 1996 11:50:49 +0200 | From | Alain KNAFF <> |
| |
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
|  |