From: | ncm(at)zembu(dot)com (Nathan Myers) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: WAL and commit_delay |
Date: | 2001-02-17 23:53:14 |
Message-ID: | 20010217155314.C16600@store.zembu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 change when pg_fsync is made to call fdatasync instead
> | of fsync? (It's in src/backend/storage/file/fd.c)
>
> I've not run this requested test, but glibc-2.2 provides this bit
> of code for fdatasync, so it /appears/ to me that kernel version
> will not affect the test case.
>
> [glibc-2.2/sysdeps/generic/fdatasync.c]
>
> int
> fdatasync (int fildes)
> {
> return fsync (fildes);
> }
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);
We can probably expect this to be fixed in an upcoming 2.4.x, i.e.
well before 2.6.
This is moot, though, if you're writing to a raw volume, which
you will be if you are really serious. Then, fsync really is
equivalent to fdatasync.
Nathan Myers
ncm(at)zembu(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Brent Verner | 2001-02-18 00:10:09 | Re: Re: WAL and commit_delay |
Previous Message | Nathan Myers | 2001-02-17 23:35:15 | Re: Microsecond sleeps with select() |