On Tue, 13 Mar 2001, Tom Lane wrote:
> > I was told the same a long ago about FreeBSD. How much can we count on
> > this undocumented sync() feature?
>
> Sounds quite unreliable to me. Unless there's some interlock ...
> like, say, the second sync not being able to advance past a buffer
> page that's as yet unwritten by the first sync. But would all Unixen
> share such a strange detail of implementation?
The Linux manpage says:
NAME
sync - commit buffer cache to disk.
[..]
DESCRIPTION
sync first commits inodes to buffers, and then buffers to
disk.
[..]
CONFORMING TO
SVr4, SVID, X/OPEN, BSD 4.3
BUGS
According to the standard specification (e.g., SVID),
sync() schedules the writes, but may return before the
actual writing is done. However, since version 1.3.20
Linux does actually wait. (This still does not guarantee
data integrity: modern disks have large caches.)
And it's still true. On a fast system, if you do:
$ cp /dev/zero /tmp & sleep 1; sync
the sync will often never finish. (Of course, that's
just an implementation detail really.)
Matthew.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
