Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47GP1wJ002567 for ; Tue, 7 May 2002 09:25:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47GP1HK002566 for linux-xfs-outgoing; Tue, 7 May 2002 09:25:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47GOrwJ002536 for ; Tue, 7 May 2002 09:24:54 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g47GL8730892; Tue, 7 May 2002 18:21:08 +0200 Date: Tue, 7 May 2002 18:21:08 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Stephen Lord Cc: Hugo Lafargue , linux-xfs@oss.sgi.com Subject: Re: Exporting xfs over nfs Message-ID: <20020507182108.S18743@vestdata.no> References: <20020507154732.HHEI7485.mtiwmhc26.worldnet.att.net@taz> <3CD7FAF2.5040601@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD7FAF2.5040601@sgi.com>; from lord@sgi.com on Tue, May 07, 2002 at 11:04:02AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g47GL8730892 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47GOswJ002537 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 11:04:02AM -0500, Stephen Lord wrote: > First of all, I presume when you fail over to the second node, you > unmount the xfs filesystem on one > box and mount it on the second one before the IP address takeover > happens? If not then there is > a good chance of corruption. Yes, that's the way it's done. Most cluster-implementations also implement some kind of fencing to make sure the original server doesn't continue accessing the disk after the second server takes over. > That aside, I think that without code changes, the only way to make this > work is to ensure that the > /dev entry used to mount the filesystem on both boxes has the same > major/minor number. If not > then I think the stale handles will result. Note this is just a guess on > my part right now, I have > not looked at this code in a while. Recently a patch was accepted to allow the user to specify the device-id to use for nfs exports - that should take care of the problem with different major/minor numbers on the two servers. But of course, having to identical servers are the easiest way. You also need to put /var/lib/nfs on shared storage, and to use the same "servicename" on both servers (-n flag in newest version of nfs-utils) for locks to work properly. There are other cavecats as well, but basicly it's possible to get it to work with a little effort. And for out-of-the-box solutions there are ofcourse NAS devices that you can buy that implement this :-) -- Ragnar Kjørstad Big Storage