Re: Clarification on client "async" option

[Malahal Naineni <malahal@us.ibm.com>]

Andrew Martin [amartin@xes-inc.com] wrote:
> ----- Original Message -----
> > From: "Trond Myklebust" <trond.myklebust@primarydata.com>
> > > This shows that a temporary filename is written and then closed, however
> > > the
> > > file is then chmodded and renamed to the final destination filename. Do the
> > > chmod(2) and rename(2) calls force a COMMIT to be sent, flushing these
> > > changes
> > > to stable storage on the NFS server? Or, is there a possibility that during
> > > a
> > > power failure of both client and server, the file would remain as
> > > .dest.y4ihWF
> > > on the server?
> > 
> > In NFSv3, the close() will cause the client to flush all data to stable
> > storage.
> > The client will also flush data to stable storage on a chmod, since
> > that could potentially affect its ability to write back the data. It
> > will not bother to do so for rename.
> > An application should normally be able to rely on the data being
> > safely on disk in both these situations provided that the server
> > honours the NFS protocol (with a caveat that an ill-timed 'kill -9'
> > could interrupt the process of flushing).
> > 
> > All metadata operations such as create, chmod, rename, etc. will cause
> > the server to flush the file metadata to disk assuming that you set
> > the (highly recommended) "sync" export option. If "sync" is set, the
> > server will also honour COMMIT requests by flushing the data to stable
> > storage.
> 
> Thanks for the clarification - I will use "sync" on the server side and
> "async" on the client side, since I know now that this combination will
> provide both data and metadata safety.

That should be the default too.