On 11/18/2011 11:37 PM, Trond Myklebust wrote:
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?
If write succeeds,
and the write rpc fails
and data is lost
and fsync succeeds
then the nfs client is broken.
d'accord?
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?
Well, the hang after step 1a.
If there is to be a hang I'd like it when the fsync is done.
(And no hang if no fsync).
--
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
