All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@google.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Robert Nelson <rlnelson@google.com>, nfs@lists.sourceforge.net
Subject: Re: [RFC] Change filesystem mount without disconnecting	clients
Date: Thu, 23 Nov 2006 14:35:56 -0800	[thread overview]
Message-ID: <4566224C.2070108@google.com> (raw)
In-Reply-To: <1164219346.5694.31.camel@lade.trondhjem.org>

Trond Myklebust wrote:
>> The suspend is accomplished by taking a write lock on the export cache's
>> hash_sem, which by fortuitous circumstance encloses all nfs transaction
>> processing.  We then flush the export cache, driving the underlying
>> filesystem mount count down to one, in which state it can be unmounted.
>> Holding the hash_sem prevents mountd from reloading the export cache.  To
>> resume, we just release the write lock.
> 
> Definitely not the correct way to do this. Causing the NFS server to
> hang for long periods of time will, for instance, cause all NFSv4 state
> to be unnecessarily lost, forcing a full state recovery. It will also
> cause UDP clients to flood the network with retries.

What is a long period of time in this context?  This suspend is only
supposed to last a second or two while we mount the new filesystem.
Will we really start losing v4 state in that time?

We have in mind to reduce the duration of the suspend to practically
nothing eventually, by mounting the new filesystem _before_ suspending.
The suspend latency in this case would be just a few milliseconds, plus
the time to suspend the longest running filesystem transaction.

We also don't suspend rpc receive, just rpc execute, which gives us a
little more breathing room before all the nfsds block on processing.  We
could go a little further in that direction by tweaking the nfsd flow
to keep receiving requests even while processing is blocked.  But maybe
we really still need to do...

> Ideally, you want to be returning NFS3ERR_JUKEBOX to the NFSv3 clients
> (or NFS4ERR_DELAY for NFSv4) in order to request that they back off and
> retry the operation later. For some operations that don't involve files
> (e.g. the NFSv4 RENEW requests, NULL RPC pings) you may actually want to
> process the request despite the disk being offline.

Ah, thanks, this will solidify the behaviour without changing the basic
approach.

Regards,

Daniel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      reply	other threads:[~2006-11-23 22:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-22  3:19 [RFC] Change filesystem mount without disconnecting clients Daniel Phillips
2006-11-22 18:15 ` Trond Myklebust
2006-11-23 22:35   ` Daniel Phillips [this message]

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=4566224C.2070108@google.com \
    --to=phillips@google.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=rlnelson@google.com \
    --cc=trond.myklebust@fys.uio.no \
    /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.