All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hughes <john@calvaedi.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: John Hughes <john@calva.com>, Jim Rees <rees@umich.edu>,
	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:46:31 +0100	[thread overview]
Message-ID: <4EC6E047.20800@calvaedi.com> (raw)
In-Reply-To: <1321655828.10541.23.camel@lade.trondhjem.org>

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).



  reply	other threads:[~2011-11-18 22:46 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
2011-11-18 22:37             ` Trond Myklebust
2011-11-18 22:46               ` John Hughes [this message]
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=4EC6E047.20800@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.