> "POSIX allows this" is an anal point. Like
> "the C standard allows this". This is not
> what standard documents are about.
To everyone whining about this behaviour because "posix allows it", it is not like a C compiler that adds some new crazy optimisation that can break any threaded program that previously was working (like speculatively writing to a variable that is never touched in logical control flow). POSIX in this case *IS* basically ratifying existing practices.
fsync() is something that you have to do on many OSes and many filesystems for a long time in order to get correct semantics. Programmers that come along a decades or two later and decide to ignore basics like that because it mostly appears to work on one filesystem on one OS cannot complain that a new filesystem or OS breaks their app really don't have a high horse on which to sit.... a mini pony at best.
It's quite fair to hope for a best effort, but it is also fair to make an appropriate choice about the performance tradeoff so that well written applications don't get horribly penalised.
Ts'o: Delayed allocation and the zero-length file problem
Posted Mar 20, 2009 13:48 UTC (Fri) by anton (guest, #25547)
[Link]
[...] it is not like a C compiler that adds some new
crazy optimisation that can break any threaded program that previously
was working (like speculatively writing to a variable that is never
touched in logical control flow)
That's actually a very good example: ext4 performs the writes in a
different order than what corresponds to the operations in the
process(es), resulting in an on-disk state that never was the logical
state of the file system at any point in time. One difference is that
file systems have been crash-vulnerable ("crazy") for a long time, so
in a variation of the Stockholm syndrome a number of people now insist
that that's the right thing.