fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching - Mailing list pgsql-hackers

From Curtis Faith
Subject fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching
Date
Msg-id DMEEJMCDOJAKPPFACMPMCECPCEAA.curtis@galtair.com
Whole thread Raw
In response to Re: Potential Large Performance Gain in WAL synching  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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
filefrom 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.


pgsql-hackers by date:

Previous
From: Giles Lean
Date:
Subject: Re: Improving backend startup interlock
Next
From: "Michael Paesold"
Date:
Subject: Re: Improving backend startup interlock