From: John Hughes <john@calvaedi.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Jim Rees <rees@umich.edu>, John Hughes <john@Calva.COM>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add "-e" option to rpc.gssd to allow error on ticket expiry. Try 2 with added man pages.
Date: Fri, 18 Nov 2011 23:33:49 +0100 [thread overview]
Message-ID: <4EC6DD4D.1010008@calvaedi.com> (raw)
In-Reply-To: <1321650239.2653.68.camel@lade.trondhjem.org>
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?)
next prev parent reply other threads:[~2011-11-18 22:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-18 14:34 [PATCH] Add "-e" option to rpc.gssd to allow error on ticket expiry. Try 2 with added man pages John Hughes
2011-11-18 18:35 ` Trond Myklebust
2011-11-18 19:19 ` John Hughes
2011-11-18 20:33 ` Trond Myklebust
2011-11-18 20:47 ` Nick Bowler
2011-11-18 20:54 ` Trond Myklebust
2011-11-18 20:57 ` Jim Rees
2011-11-18 21:03 ` Trond Myklebust
2011-11-18 22:33 ` John Hughes [this message]
2011-11-18 22:37 ` Trond Myklebust
2011-11-18 22:46 ` John Hughes
2011-11-18 22:08 ` John Hughes
2011-11-18 22:38 ` Trond Myklebust
2011-11-18 22:57 ` John Hughes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC6DD4D.1010008@calvaedi.com \
--to=john@calvaedi.com \
--cc=Trond.Myklebust@netapp.com \
--cc=john@Calva.COM \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=rees@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox