From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Petr Vandrovec" Subject: Re: CIFS VFS Date: Tue, 1 Oct 2002 22:00:39 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <363C9E44237@vcnet.vc.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com Return-path: To: Matthew Wilcox List-Id: linux-fsdevel.vger.kernel.org On 1 Oct 02 at 19:42, Matthew Wilcox wrote: > > On Tue, Oct 01, 2002 at 12:30:28PM -0500, Steven French wrote: > > 8) Byte Range and File locks > > there's some changes in progress around file locking in 2.5... let > me know your requirements. If I can place ncpfs's requirements here... For ncpfs easiest interface would be one which: (1) does not merge locks; Netware does not do that, you must release exact records you locked, otherwise unlock will fail. (2) first resolve locks locally, and then, if you succesfully obtained lock locally, consult filesystem's lock method; ncpfs must do it that way because of there is only one server filehandle for each opened file, and so from server's view there is only one entity on connection. I would be also satisfied with interface F_GETLK uses: call default posix_test_lock only if filesystem returned LOCK_USE_CLNT: in such case filesystem can return < 0 on failure, LOCK_USE_CLNT when lock succeeded, but kernel should do local bookkeeping itself, or 0 when lock succeeded, and inode's i_flock was already updated. If current method (first call filesystem, then obtain lock locally) is going to stay, then I believe that we should call F_UNLOCK when filesystem's lock succeeded, but local posix_lock_file failed (either due to EAGAIN or EINTR or ...). Otherwise server is never notified that lock was not acquired by workstation, and will be never released. Petr Vandrovec vandrove@vc.cvut.cz