Date: Tue, 14 May 2002 22:57:54 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Richard Sharpe <rsharpe@ns.aus.com> Cc: freebsd-hackers@freebsd.org Subject: Re: File locking, closes and performance in a distributed filesystemenv Message-ID: <3CE1F8E2.868B2965@mindspring.com> References: <Pine.LNX.4.33.0205151117270.5078-100000@ns.aus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Sharpe wrote:
> Hmmm, I wasn't very clear ...
>
> What I am proposing is a 'simple' fix that simply changes
>
> p->p_flag |= P_ADVLOCK;
>
> to
>
> fp->l_flag |= P_ADVLOCK;
>
> And never resets it, and then in closef,
>
> if ((fp->l_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);
> }
>
> Which still means that the correct functionality is implemented, but we
> only try to unlock files that have ever been locked before, or where we
> are sharing a file struct with another (related) process and one of them
> has locked the file.
Do you expect to share the same "fp" between multiple open
instances for a given file within a single process?
I think your approach will fail to implement proper POSIX
file locking semantics.
I really hate POSIX semantics, but you have to implement
them exactly (at least by default), because programs are
written to expect them.
Basically, this means that if you open a file twice, lock it
via the first fd, then close the second fd, all locks are
released. In your code, it looks like what would happen is
that when you closed the second fd, the fp->l_flag won't have
the bit set. Correct me if I'm wrong?
The reason for the extra overhead now is that you can't do
this on an open instance basis because of POSIX, so it does it
on a process instance basis.
The only other alternative is to do it on a vp basis -- and
since multiple fp's can point to the same vp, your option #2
will fail, as described above, but my suggestion to do the
locking locally will associate it the the vp (or the v_data,
depending on which version of FreeBSD, and where the VOP_ADVLOCK
hangs the lock list off of: the vnode or the inode) will
maintain the proper semantics.
Your intent isn't really to avoid the VOP_ADVLOCK call, it's
to avoid making an RPC call to satisfy the VOP_ADVLOCK call,
right?
You can't really avoid *all* the "avoidable overhead", without
restructuring the VOP_ADVLOCK interface, which is politically
difficult.
-- Terry
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?3CE1F8E2.868B2965>