fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching

From: "Curtis Faith" <curtis(at)galtair(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching
Date: 2002-10-04 23:32:49
Message-ID: DMEEJMCDOJAKPPFACMPMCECPCEAA.curtis@galtair.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

After some research I still hold that fsync blocks, at least on
FreeBSD. Am I missing something?

Here's the evidence:

Code from: /usr/src/sys/syscalls/vfs_syscalls

int
fsync(p, uap)
struct proc *p;
struct fsync_args /* {
syscallarg(int) fd;
} */ *uap;
{
register struct vnode *vp;
struct file *fp;
vm_object_t obj;
int error;

if ((error = getvnode(p->p_fd, SCARG(uap, fd), &fp)) != 0)
return (error);
vp = (struct vnode *)fp->f_data;
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
if (VOP_GETVOBJECT(vp, &obj) == 0)
vm_object_page_clean(obj, 0, 0, 0);
if ((error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p)) == 0 &&
vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP) &&
bioops.io_fsync)
error = (*bioops.io_fsync)(vp);
VOP_UNLOCK(vp, 0, p);
return (error);
}

Notice the calls to:

vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
..
VOP_UNLOCK(vp, 0, p);

surrounding the call to VOP_FSYNC.

From the man pages for VOP_UNLOCK:

HEADER STUFF .....

VOP_LOCK(struct vnode *vp, int flags, struct proc *p);

int
VOP_UNLOCK(struct vnode *vp, int flags, struct proc *p);

int
VOP_ISLOCKED(struct vnode *vp, struct proc *p);

int
vn_lock(struct vnode *vp, int flags, struct proc *p);

DESCRIPTION
These calls are used to serialize access to the filesystem, such as to
prevent two writes to the same file from happening at the same time.

The arguments are:

vp the vnode being locked or unlocked

flags One of the lock request types:

LK_SHARED Shared lock
LK_EXCLUSIVE Exclusive lock
LK_UPGRADE Shared-to-exclusive upgrade
LK_EXCLUPGRADE First shared-to-exclusive upgrade
LK_DOWNGRADE Exclusive-to-shared downgrade
LK_RELEASE Release any type of lock
LK_DRAIN Wait for all lock activity to end

The lock type may be or'ed with these lock flags:

LK_NOWAIT Do not sleep to wait for lock
LK_SLEEPFAIL Sleep, then return failure
LK_CANRECURSE Allow recursive exclusive lock
LK_REENABLE Lock is to be reenabled after drain
LK_NOPAUSE No spinloop

The lock type may be or'ed with these control flags:

LK_INTERLOCK Specify when the caller already has a simple
lock (VOP_LOCK will unlock the simple lock
after getting the lock)
LK_RETRY Retry until locked
LK_NOOBJ Don't create object

p process context to use for the locks

Kernel code should use vn_lock() to lock a vnode rather than calling
VOP_LOCK() directly.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paesold 2002-10-04 23:42:08 Re: Improving backend startup interlock
Previous Message Giles Lean 2002-10-04 23:24:55 Re: Improving backend startup interlock