Return-Path: Received: from mx2.netapp.com ([216.240.18.37]:61511 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932150Ab0IGRGa convert rfc822-to-8bit (ORCPT ); Tue, 7 Sep 2010 13:06:30 -0400 Subject: Re: [RFC][PATCH] nfs: support legacy NFS flock behavior via mount option From: Trond Myklebust To: Jeff Layton Cc: Suresh Jayaraman , Neil Brown , Linux NFS mailing list In-Reply-To: <20100907120847.692bd32e@tlielax.poochiereds.net> References: <4C84DFA7.7050507@suse.de> <1283869039.4291.16.camel@heimdal.trondhjem.org> <20100907120847.692bd32e@tlielax.poochiereds.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 07 Sep 2010 13:06:11 -0400 Message-ID: <1283879171.2788.4.camel@heimdal.trondhjem.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Tue, 2010-09-07 at 12:08 -0400, Jeff Layton wrote: > On Tue, 07 Sep 2010 10:17:19 -0400 > Trond Myklebust wrote: > > > On Mon, 2010-09-06 at 18:03 +0530, Suresh Jayaraman wrote: > > > NFS clients since 2.6.12 support flock()locks by emulating the > > > BSD-style locks in terms of POSIX byte range locks. So the NFS client > > > does not allow to lock the same file using both flock() and fcntl > > > byte-range locks. > > > > > > For some Windows applications which seem to use both share mode locks > > > (flock()) and fcntl byte range locks sequentially on the same file, > > > the locking is failing as the lock has already been acquired. i.e. the > > > flock mapped as posix locks collide with actual byte range locks from > > > the same process. The problem was observed on a setup with Windows > > > clients accessing Excel files on a Samba exported share which is > > > originally a NFS mount from a NetApp filer. Since kernels < 2.6.12 does > > > not support flock, what was working (as flock locks were local) in > > > older kernels is not working with newer kernels. > > > > > > This could be seen as a bug in the implementation of the windows > > > application or a NFS client regression, but that is debatable. > > > In the spirit of not breaking existing setups, this patch adds mount > > > options "flock=local" that enables older flock behavior and > > > "flock=fcntl" that allows the current flock behavior. > > > > So instead of having a special option for flock only, what say we rather > > introduce an option of the form > > > > -olocal_lock= > > > > which can take the values 'none', 'flock', 'fcntl' (or 'posix'?) and > > 'all'? > > > > Cheers > > Trond > > Another thought -- we already have "-olock" and "-onolock" and we'll > have to keep them for compatability. Maybe this should be "-oflock" and > "-onoflock"? > No thanks. That would require us to add a -onofcntl too, since -onolock is already defines as being equivalent to -olocal_lock=all Trond