From owner-freebsd-hackers Wed May 15 10:53:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.aus.com (adsl-64-175-246-152.dsl.sntc01.pacbell.net [64.175.246.152]) by hub.freebsd.org (Postfix) with ESMTP id 59D3037B854 for ; Wed, 15 May 2002 10:46:18 -0700 (PDT) Received: from localhost (rsharpe@localhost) by ns.aus.com (8.11.6/8.11.6) with ESMTP id g4FIpfT03484; Thu, 16 May 2002 04:21:41 +0930 Date: Thu, 16 May 2002 04:21:41 +0930 (CST) From: Richard Sharpe To: Terry Lambert Cc: Subject: Re: File locking, closes and performance in a distributed filesystemenv In-Reply-To: <3CE1F8E2.868B2965@mindspring.com> 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 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