From owner-freebsd-hackers Tue May 14 9:21:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.aus.com (adsl-64-175-245-157.dsl.sntc01.pacbell.net [64.175.245.157]) by hub.freebsd.org (Postfix) with ESMTP id A26D137B405 for ; Tue, 14 May 2002 09:21:53 -0700 (PDT) Received: from localhost (rsharpe@localhost) by ns.aus.com (8.11.6/8.11.6) with ESMTP id g4EHVC403265 for ; Wed, 15 May 2002 03:01:12 +0930 Date: Wed, 15 May 2002 03:01:12 +0930 (CST) From: Richard Sharpe To: Subject: File locking, closes and performance in a distributed file system env Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I might be way off base here, but we have run into what looks like a performance issue with locking and file closes. We have implemented a distributed file system and were looking at some performace issues. At the moment, if a process locks a file, the code in kern_descrip.c that handles it does the following: p->p_flag |= P_ADVLOCK; to indicate that files might be locked. Later in closef, we see the following: if (p && (p->p_flag & P_ADVLOCK) && fp->f_type == DTYPE_VNODE) { lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; lf.l_type = F_UNLCK; vp = (struct vnode *)fp->f_data; (void) VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_UNLCK, &lf, F_POSIX); } This seems to mean that once a process locks a file, every close after that will pay the penalty of calling the underlying vnode unlock call. In a distributed file system, with a simple implementation, that could be an RPC to the lock manager to implement. Now, there seems to be a few ways to migitate this: 1. Keep (more) state at the vnode layer that allows us to not issue a network traversing unlock if the file was not locked. This means that any process that has opened the file will have to issue the network traversing unlock request once the flag is set on the vnode. 2. Place a flag in the struct file structure that keeps the state of any locks on the file. This means that any processes that share the struct (those related by fork) will need to issue unlock requests if one of them locks the file. 3. Change a file descriptor table that hangs off the process structure so that it includes state about whether or not this process has locked the file. It seems that each of these reduces the performance penalty that processes that might be sharing the file, but which have not locked the file, might have to pay. Option 2 looks easy. Are there any comments? Regards ----- Richard Sharpe, rsharpe@ns.aus.com, rsharpe@samba.org, sharpe@ethereal.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message