Return-Path: Received: from fieldses.org ([174.143.236.118]:51354 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932272Ab0KSVsa (ORCPT ); Fri, 19 Nov 2010 16:48:30 -0500 Date: Fri, 19 Nov 2010 16:48:27 -0500 From: "J. Bruce Fields" To: Trond Myklebust Cc: Moazam Raja , linux-nfs@vger.kernel.org Subject: Re: O_DIRECT, O_SYNC, or fsync() on NFS mounts? Message-ID: <20101119214827.GB3143@fieldses.org> References: <1290194699.3135.49.camel@heimdal.trondhjem.org> <20101119200421.GA3143@fieldses.org> <1290201995.3135.63.camel@heimdal.trondhjem.org> Content-Type: text/plain; charset=us-ascii In-Reply-To: <1290201995.3135.63.camel@heimdal.trondhjem.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Fri, Nov 19, 2010 at 04:26:35PM -0500, Trond Myklebust wrote: > On Fri, 2010-11-19 at 15:04 -0500, J. Bruce Fields wrote: > > On Fri, Nov 19, 2010 at 02:24:59PM -0500, Trond Myklebust wrote: > > > On Thu, 2010-11-18 at 15:34 -0800, Moazam Raja wrote: > > > > Hi all, > > > > > > > > I'm currently exporting a ZFS filesystem on Solaris 11 Express as NFS. > > > > I have a Linux client mounting that NFS v3 filesystem with the > > > > proto=tcp option. > > > > > > > > My question is, what's the safest and most reliable way to write data > > > > to this NFS mount on a Linux client? Should my application code use > > > > O_DIRECT, or O_SYNC? Or should I be doing a write() and a fsync()? I > > > > want to make sure that data is not lost and is truly committed, while > > > > keeping decent performance (of course). > > > > > > Any one of the above methods will ensure that the data is synced to > > > disk. In addition, NFS also guarantees that your data is fully synced to > > > disk when taking/freeing POSIX locks, and when you close() the file. > > > > Is the client still doing that in the presence of a write delegation, by > > the way? > > If the application requests O_DIRECT/O_SYNC or calls fsync(), we are > required by POSIX to ensure the data is safe on disk. The presence of an > NFS delegation does not change that requirement. > > We could potentially relax the sync-to-disk requirements when locking > and closing the file since those are only about ensuring close-to-open > cache consistency requirements (which is also ensured by the delegation) > but we do not do so today. OK, that makes sense. We probably shouldn't say in that case that we "guarantee" the sync on close/free, if we consider it a detail of the current implementation rather than a requirement. --b.