From: James Pearson <james-p@moving-picture.com>
To: David Dougall <davidd@et.byu.edu>
Cc: "nfs@lists.sourceforge.net" <nfs@lists.sourceforge.net>
Subject: Re: file system handle
Date: Mon, 13 Dec 2004 15:57:50 +0000 [thread overview]
Message-ID: <41BDBBFE.5090406@moving-picture.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0412130839540.13290@lewis.et.byu.edu>
Yes - existing clients will still use the 'default' filehandle type. Any
new clients will use the fsid= option type. You have to make sure all
clients have remounted the file systems before moving the disks to a new
host.
James Pearson
David Dougall wrote:
> So, you are saying that if I add an fsid= option into the exports, the
> server will work with both that filehandle and the default major/minor
> number one?
> --David Dougall
>
>
> On Mon, 13 Dec 2004, James Pearson wrote:
>
>
>>David Dougall wrote:
>>
>>>I am moving filesystems/disks to new NFS servers. They are going to
>>>change major and minor numbers. Is there any way I can prevent stale
>>>mounts with the fsid= option in the exports?
>>>I have tried this on a test environment, but when I try to create an fsid=
>>>option, it completely changes the filehandle format in the nfs packet. Am
>>>I missing something, or are the default and forced fsid options
>>>incompatible?
>>
>>I believe using the fsid= option does use a different file handle id
>>type, so you can't directly do what you want with the fsid option.
>>
>>However, you can re-export a file system with an added fsid= option -
>>any existing mounts will still use the 'previous' file handle type based
>>on the device id, but new mounts will use the new fsid file handle. You
>>then will have to make sure all existing clients remount the file system
>>before moving the disks.
>>
>>I've done this before - but I had to make the export change well in
>>advance, so that I could make sure all existing clients remounted the
>>file system before the move.
>>
>>James Pearson
>>
>>
>>
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2004-12-13 15:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-13 15:12 file system handle David Dougall
2004-12-13 15:30 ` James Pearson
2004-12-13 15:41 ` David Dougall
2004-12-13 15:57 ` James Pearson [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=41BDBBFE.5090406@moving-picture.com \
--to=james-p@moving-picture.com \
--cc=davidd@et.byu.edu \
--cc=nfs@lists.sourceforge.net \
/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.