From owner-freebsd-fs@FreeBSD.ORG Sat Aug 30 11:47:01 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17E8ACB2; Sat, 30 Aug 2014 11:47:01 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B259F1198; Sat, 30 Aug 2014 11:47:00 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAFO5AVSDaFve/2dsb2JhbABbg2BXBIJ4xHuHTAGBJ3eEBAEFI1YbDgoCAg0ZAlkGiFUNpn6UfgEXgSyNbTQHgnmBUwWodYkFg30hLwEBgUaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,431,1406606400"; d="scan'208";a="150686617" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 30 Aug 2014 07:46:59 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2CEFDB3EA2; Sat, 30 Aug 2014 07:46:59 -0400 (EDT) Date: Sat, 30 Aug 2014 07:46:59 -0400 (EDT) From: Rick Macklem To: Don Lewis Message-ID: <1588968883.30624902.1409399219119.JavaMail.root@uoguelph.ca> In-Reply-To: <201408300051.s7U0peLr073400@gw.catspoiler.org> Subject: Re: lockf(1) and NFS MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-fs@FreeBSD.org, ivoras@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 11:47:01 -0000 Don Lewis wrote: > On 29 Aug, Rick Macklem wrote: > > Ivan Voras wrote: > >> Hi, > >> > >> I had some fun troubleshooting NFS locking and among other things, > >> found > >> that lockf(1) doesn't really work on NFSv4 mounts. Googling around > >> (so > >> correct me if I'm wrong), it looks like this is because NFS > >> quietly > >> translates the old-style locks into POSIX range locks, and those > >> cannot > >> be acquired exclusively if the file is opened read-only. > >> > > Yes, the NFSv4 protocol only supports POSIX byte range locks. > > The only alternative to translating flock(2) locks to POSIX locks > > is > > to not support flock(2) locks at all. > > As I recall, on SunOS, flock(2) locks were local to the machine. > Looks > like that was changed later on ... > > "Locks obtained through the flock() mechanism under SunOS 4.1 > were known only within the system on which they were placed. > This is no longer true." > > > > That was actually a feature because you could use flock() to > coordinate > between local processes, while avoiding any NFS lock manager bugs, > even > on diskless machines. > > > Doing locking locally within the client is still possible with the "nolockd" option. However, when this mount option is used all file locking, including POSIX byte range locks, are done locally. Linux has a similar mount option (called "nolock" I think?), but I don't know if Solaris has any mount option. I'm pretty sure Ivan knows about this, so I suspect he needs lockf(1) to work across multiple clients for his app., but don't know for sure? rick