On Fri, 2011-11-18 at 23:33 +0100, John Hughes wrote: > On 11/18/2011 10:03 PM, Trond Myklebust wrote: > > On Fri, 2011-11-18 at 15:57 -0500, Jim Rees wrote: > > > >> > >> The write() syscall doesn't indicate whether the data is safe or not. That > >> would be the close() syscall. > >> > > fsync(). Which may succeed if the user renews their ticket first. > > However you may still have data loss if dirty data has been lost because > > of EKEYEXPIRED returns on the WRITE RPC call... > > > Only if the write(2) returned EKEYEXPIRED, surely, What part of "write is asynchronous" is so hard to understand? > > Also, for the fsync() to return EKEYEXPIRED _after_ the user has renewed > > their ticket would seem counter-intuitive to most people. > > > > I would want to know if data was lost. > > Intuition means nothing if I get an error. > > If it were possible I'd like: > > 1. write works > 1a. WRITE RPC fails, data stays in cache > 2. ticket renewed > 3. fsync works, data written Which is _exactly_ how it works today, so what is the problem? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
