Date: Wed, 15 May 2002 03:01:12 +0930 (CST) From: Richard Sharpe <rsharpe@ns.aus.com> To: <freebsd-hackers@freebsd.org> Subject: File locking, closes and performance in a distributed file system env Message-ID: <Pine.LNX.4.33.0205150251310.3047-100000@ns.aus.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0205150251310.3047-100000>