Date: Thu, 16 May 2002 04:21:41 +0930 (CST) From: Richard Sharpe <rsharpe@ns.aus.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: <freebsd-hackers@freebsd.org> Subject: Re: File locking, closes and performance in a distributed filesystemenv Message-ID: <Pine.LNX.4.33.0205160417350.3424-100000@ns.aus.com> In-Reply-To: <3CE1F8E2.868B2965@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 May 2002, Terry Lambert wrote:
> 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.
OK, you have convinced me. I have looked at the POSIX spec in this area,
and agree that I can't do what I want to do.
> 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?
Yes, correct. We will have to do it in the vnode layer as you suggest.
Currently we are using 4.3 and moving to 4.5, so we will have to figure
out the differences.
> You can't really avoid *all* the "avoidable overhead", without
> restructuring the VOP_ADVLOCK interface, which is politically
> difficult.
I wouldn't want to try. Too much code to change and too much chance of a
massive screw-up.
Thanks for perservering with me.
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.0205160417350.3424-100000>