All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Greg <greg-sys@duchatelet.net>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Relocate NFS root FS for maintenance
Date: Thu, 2 Sep 2010 12:06:27 -0400	[thread overview]
Message-ID: <20100902160627.GH13117@fieldses.org> (raw)
In-Reply-To: <4C7F5302.30300@duchatelet.net>

On Thu, Sep 02, 2010 at 09:32:18AM +0200, Greg wrote:
>  Tom,
> 
> >
> >What you are missing here is that the client uses two things to
> >access content on
> >the servers - path and file handles. When you do the reshare, you
> >would be pointing any
> >new requests to the empty directories. But, any application which
> >already had a
> >file handle would have a reference to the old mount (via the fsid
> >part of the file handle).
> 
> OK thanks for the precisions. It's why I'm getting those errors :
> Sep  1 15:12:53 varan-14 kernel: [3424547.256518] NFS: server
> filer-large-vip.local error: fileid changed
> Sep  1 15:12:53 varan-14 kernel: [3424547.256518] fsid 0:13:
> expected fileid 0x2, got 0x41
> 
> >The options I see are to:
> >
> >1) Shutdown NFS/remove write access to the export/etc - this is
> >along the lines of what
> >you have done. And the result is that the server will inform the
> >client of an error.
> >
> >2) Disconnect the servers from the network. (Or partition the
> >network). In this scenario,
> >the client will be getting timeouts and will probably use a retry schema.
> >
> >3) Shutdown the NFS clients - harsh, but they will not be
> >accessing the servers and you
> >can easily do the upgrades.
> >
> >These all result in downtime for both your servers and your clients.
> 
> So in short there is no way to do a maintenance on attached storage,
> could it be hard drives, RAID, iSCSI or anything.
> Is such a "feature" in the roadmap ?

I think I just don't understand your setup, because I'm confused about
what you're asking for.  (If the thing you're upgrading is literally the
only path between the nfs servers and their storage, then what can we
do?)

Would you mind explaining again from the start exactly what you're setup
is and what you're hoping to accomplish by moving these mountpoints?
Apologies for being dense!

--b.

  reply	other threads:[~2010-09-02 16:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01 12:17 Relocate NFS root FS for maintenance Greg
2010-09-01 17:34 ` J. Bruce Fields
2010-09-01 21:52 ` Tom Haynes
2010-09-02  7:32   ` Greg
2010-09-02 16:06     ` J. Bruce Fields [this message]
2010-09-07  6:59       ` Greg
2010-09-02  6:56 ` statfs() gives ESTALE error Menyhart Zoltan
2010-09-07 18:32   ` Trond Myklebust
2010-09-08 13:33 ` Re :statfs() " Menyhart Zoltan
2010-09-08 20:25   ` Trond Myklebust
2010-09-09  8:12 ` Menyhart Zoltan
2010-09-20 12:49 ` Locking question around "...PagePrivate()" Menyhart Zoltan
2010-09-20 13:55   ` Trond Myklebust
2010-10-05  8:22 ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-21 20:38   ` J. Bruce Fields
2010-10-22 15:00     ` Menyhart Zoltan
2010-10-22 21:20       ` J. Bruce Fields
2010-10-22 23:01         ` J. Bruce Fields
2010-10-22 23:21           ` J. Bruce Fields
2010-10-23  3:32             ` J. Bruce Fields
2010-10-25  1:09               ` J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 1/4] svcrpc: never clear XPT_BUSY on dead xprt J. Bruce Fields
2010-10-25  1:43                   ` Neil Brown
2010-10-25 20:21                     ` J. Bruce Fields
2010-10-25 22:58                       ` Neil Brown
2010-10-25 23:03                         ` J. Bruce Fields
2010-10-25 23:54                           ` Neil Brown
2010-10-26  0:11                             ` J. Bruce Fields
2010-10-26  0:28                               ` J. Bruce Fields
2010-10-26  0:30                                 ` J. Bruce Fields
2010-10-26  1:28                                   ` Neil Brown
2010-10-26 12:59                                     ` J. Bruce Fields
2010-10-26 16:05                                       ` J. Bruce Fields
2010-11-12 19:00                                         ` J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 2/4] svcrpc: assume svc_delete_xprt() called only once J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 3/4] svcrpc: no need for XPT_DEAD check in svc_xprt_enqueue J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 4/4] svcrpc: svc_tcp_sendto XTP_DEAD check is redundant J. Bruce Fields
2010-10-25  2:10                   ` Neil Brown
2010-10-25 15:03                     ` J. Bruce Fields
2010-10-25 17:46                       ` J. Bruce Fields
2010-10-25 23:08                         ` Neil Brown
2010-10-26  1:33                           ` J. Bruce Fields
2010-10-25 23:23                       ` Neil Brown
2010-10-26  1:25                         ` J. Bruce Fields
2010-10-25 11:56         ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-25 14:36           ` J. Bruce Fields

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=20100902160627.GH13117@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=greg-sys@duchatelet.net \
    --cc=linux-nfs@vger.kernel.org \
    /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.