From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Experimental ARC implementation |
Date: | 2003-11-07 20:53:26 |
Message-ID: | 3FAC0646.3060007@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
>
>
>>>I am not really aiming at removing sync() alltogether. We know already
>>>that open,fsync,close does not guarantee you flush dirty OS-buffers for
>>>which another process might so far only have done open,write. And you
>>>
>>>
>
>So for what it's worth, though the spec seems to indicate fsync is only
>guaranteed to sync writes to that file descriptor, in reality all known VFS's
>do not associated dirty buffers with particular file descriptors.
>
>At least I checked with people that NetBSD and Solaris do not. Both developers
>said they were unaware of any OS that kept dirty buffers per-fd and couldn't
>imagine anyone wanting to do that. It would be fairly easy to check Linux. All
>the others out there are fairly closely related to either NetBSD or Solaris.
>
>
The Linux man page for fsync says this:
fsync copies all in-core parts of a file to disk, and waits
until the
device reports that all parts are on stable storage. It also
updates
metadata stat information.
which seems to imply similar behaviour on Linux as for other OSs. What I
could understand of the source code in mm/filemap.c and fs/buffer.c
appeared to confirm that.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-11-07 20:55:19 | Re: stats collector causes shared-memory-block leakage |
Previous Message | Christopher Browne | 2003-11-07 20:36:55 | Re: [HACKERS] Changes to Contributor List |