* bmccoy@chapelperilous.net <bmccoy@chapelperilous.net> [001031 12:28] wrote:
> "Gary Howland (During daytime)" wrote:
>
> > Just a quickie - I heard that linux does not have a working fsync()
> > call (it has no concept of raw devices). In other words, fsync cannot
> > be used to ensure that data is on disk (try it with a floppy - it
> > returns IMMEDIATELY!!! - long before the write finishes)
>
> That's because the mounted drive is buffered in memory, so when you copy a
> file, you are copying it to memory (which is very fast), and the kernel
> implicitly syncs with the media when the buffer fills or when an explicit
> sync is done or when it is unmounted.
>
> If there is no working fsync (and fdatasync), why do the Linux man pages
> claim it to be POSIX.1b compliant?
>
> Can you back up your claim with actual documentation? Saying 'I heard'
> puts it in the realm of urban legendry...
You guys are missing the difference between fsync(2) and sync(1),
on Linux fsync(2) (called on a file descriptor) WILL sync out all
the data halfway to specification, HOWEVER afaik it will not fsync
out all directory entries that may contain this file.
If this is still true, that means that on Linux you must walk '..'
calling fsync on each directory above the file before considering
the file really there.
Now sync(2) and sync(1) (the userland interface to the sync(2)
syscall) work beyond the spec, on Linux sync(2) shouldn't return
until all data has been sync'd to disk, however the standard only
says that sync(2) should schedule the data to be sync'd out, not
that it needs to wait until it's all done.
<blatant plug>
Of course FreeBSD fsync(2) does properly walk '..' for you and
sync(2) behaves as specified by spec, mearly scheduling the IO,
not doing it syncronously.
</blatant plug>
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
