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
