public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
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?)


  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