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,
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
But:
1. write...
1a. WRITE RPC fails
1b. ... fails
seems ok.
Even
1. write works
1a WRITE RPC fails
2. ticket renewed
3. fsync fails
would be ok for me. (light cone problems?)
--
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
