Andrew Martin [amartin@xxxxxxxxxxx] wrote: > ----- Original Message ----- > > From: "Trond Myklebust" <trond.myklebust@xxxxxxxxxxxxxxx> > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
