Patrick O'Callaghan wrote:
On Thu, 2008-04-24 at 10:49 -0400, Joe Smith wrote:
...
I'm not convinced that using sync(1) would be effective, especially from
the desktop environment where who knows what processes have something
open on a pluggable device. Sync would be prudent if you were moving raw
data blocks to a device, but not for mounted filesystems.
Of course sync is effective for mounted filesystems, why wouldn't it be?
It means data are now synched *up to this point*.
By "not effective" I don't mean that it doesn't work, I mean that it
can't guarantee that the device is safe to remove. What's to stop
something from starting a write to the device 10us after the kernel
syncs all the buffers? The sync+unmount has to be atomic in order to
guarantee that the data buffers are flushed and that nothing else can
start a new write. unmount(2) is the logical (only?) place to lock the
two operations together.
...
There is no documentary evidence that unmount calls sync (contrary to
what many people think, including me up to about yesterday). The
eject(1) page doesn't mention syncing or flushing buffers.
A man page is usually an afterthought, not a spec. A unix without
incomplete man pages wouldn't be unix ;-)
As you yourself pointed out, even a look at the source code won't prove
it. If you have evidence that umount (or eject) alone is not sufficient
to flush all pending i/o for the device, then it should be reported as a
bug.
Use "sync && umount" if you like, there's no harm in it, but sync alone
is not a substitute for umount. eject(1) can safely substitute for
umount, because eject is designed to unmount the device.
<Joe
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
