Tom Lane wrote:
Adriaan Joubert [EMAIL PROTECTED] writes:
fdatasync() is available on Tru64 and according to the man-page behaves
as Tom expects. So it should be a win for us.
Careful ... HPUX's man page also claims that fdatasync does something
useful, but it doesn't. I'd recommend an
Adriaan Joubert [EMAIL PROTECTED] writes:
fdatasync() is available on Tru64 and according to the man-page behaves
as Tom expects. So it should be a win for us.
Careful ... HPUX's man page also claims that fdatasync does something
useful, but it doesn't. I'd recommend an experiment. Does
Larry Rosenman [EMAIL PROTECTED] writes:
BTW, UnixWare 7.1.1 does *NOT* have fdatasync. What standard created
this one?
HP's manpage quoth:
STANDARDS CONFORMANCE
fsync(): AES, SVID3, XPG3, XPG4, POSIX.4
fdatasync(): POSIX.4
regards, tom lane
On Sun, Feb 18, 2001 at 11:51:50AM -0500, Tom Lane wrote:
Adriaan Joubert [EMAIL PROTECTED] writes:
fdatasync() is available on Tru64 and according to the man-page behaves
as Tom expects. So it should be a win for us.
Careful ... HPUX's man page also claims that fdatasync does something
On Sat, Feb 17, 2001 at 06:30:12PM -0500, Brent Verner wrote:
On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote:
[snipped]
| Is anyone out there running a 2.4 Linux kernel? Would you try pgbench
| with current sources, commit_delay=0, -B at least 1024, no -F, and see
| how the results
[EMAIL PROTECTED] (Nathan Myers) writes:
In the 2.4 kernel it says (fs/buffer.c)
/* this needs further work, at the moment it is identical to fsync() */
down(inode-i_sem);
err = file-f_op-fsync(file, dentry);
up(inode-i_sem);
Hmm, that's the same code that's been there since
[EMAIL PROTECTED] (Nathan Myers) writes:
I.e. yes, Linux 2.4.0 and ext2 do implement the distinction.
Sorry for the misinformation.
Okay ... meanwhile I've got to report the reverse: I've just confirmed
that on HPUX 10.20, there is *not* a distinction between fsync and
fdatasync. I was misled
