Re: Re: WAL and commit_delay

On 17 Feb 2001 at 15:53 (-0800), Nathan Myers wrote:
| 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.

2.4.0-ac11 already has provisions for fdatasync 

[fs/buffer.c]
 352 asmlinkage long sys_fsync(unsigned int fd) 353 {     ... 372   down(&inode->i_sem); 373
filemap_fdatasync(inode->i_mapping);374   err = file->f_op->fsync(file, dentry, 0); 375
filemap_fdatawait(inode->i_mapping);376   up(&inode->i_sem);
 
 384 asmlinkage long sys_fdatasync(unsigned int fd) 385 {     ... 403   down(&inode->i_sem); 404
filemap_fdatasync(inode->i_mapping);405   err = file->f_op->fsync(file, dentry, 1); 406
filemap_fdatawait(inode->i_mapping);407   up(&inode->i_sem);
 

ext2 does use this third param of its fsync() operation to (potentially)
bypass a call to ext2_sync_inode(inode)
 b