On Thu, 2005-06-30 at 11:46 -0700, Chris Wedgwood wrote:
> Yes, but POSIX is broken in places. The linux implmentation (now and
> for sometime but not always) won't return until all dirty data is
POSIX, in regard to fsync() provides "flexibility for the
implementation" - maybe your environment is special and you don't buffer
anything, so fsync() is null. Or perhaps you cannot control some of the
disk caches, so fsync() is null.
In newer systems, you can check for the flag POSIX_SYNCHRONIZED_IO (or
similar) that, if set, gaurentees that fsync() is synchronously flushing
buffers to disk. However, this only came into the spec in 99 or 2000 i
think, so there are still a lot of systems in which you have to know the
> > and some 'sync' programs do multiple sync()s.
> Such programs are arguably broken (grub maybe?). If one doesn't work,
> then why should doing it <n>-times?
It's a legacy from the days when it was an async operation. The idea
went: that the time it took to type sync and press enter three times
(note, no using up-arrow, enter - typing) would be long enough for the
buffers that started to get flushed on the first sync to have hit disk.
> > And it's also filesystem-type-dependent.
> If a filesystem doesn't flush reliably with sync, I would call that a
> > fsync(), on the other hand, is a true synchronizing operation.
> Again that requires the fs to behave correctly so if it fails it
> should be reported as a bug.
It's all fun and games - reliably getting data to disk is not fun. If
Linux can reliably follow the idea that fsync() is synchronous and
really does flush everything to disk, then it will be a lot better off
then a lot of other platforms.
Also, it'd be useful to have a list of where bugs affecting this have
been found and in what kernels - It is not out of the question
explicitly coding in exceptions (read: big warnings to users) for these
I guess a list of known-bad drives and controllers could be useful too.
Doubly useful if the kernel could report this, but a userspace list
would also be good.
Stewart Smith (stewart@xxxxxxxxxxxxxxxx)
Description: This is a digitally signed message part