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
