Re: RE: xlog checkpoint depends on sync() ... seems uns afe

From: Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Dominic J(dot) Eidson'" <sauron(at)the-infinite(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RE: xlog checkpoint depends on sync() ... seems uns afe
Date: 2001-03-13 10:49:00
Message-ID: Pine.LNX.4.10.10103131046510.14830-100000@sphinx.mythic-beasts.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-03-13 10:52:30 AW: RE: xlog loose ends, continued
Previous Message Denis Perchine 2001-03-13 10:06:48 Re: Performance monitor