10:03 a.m.
Thank you,
this makes it clear, the existing nfs clients need to unmount/mount. As the FSID
changes we probably best reboot the clients to make them for sure forget
about any previously cached fsid for the same nfs server IP. (We'll move the nfs
server IP from the old kernel nfsd server to the new ganesha server during
migration)
Once the clients are unmounted, I don't think you have to worry about the fsid.
Frank
Kind regards,
Heiner Billich
--
Paul Scherrer Institut
Science IT
Heiner Billich
WHGA 106
CH 5232 Villigen PSI
056 310 36 02
https://www.psi.ch
On 26/07/18 16:35, "Frank Filz" <ffilzlnx(a)mindspring.com> wrote:
> Hello,
>
> currently we export a GPFS file system via kernel nfsd (RHEL6). Now we will
> migrate to ganesha 2.5. I wonder whether we can do this in a transparent
way,
> i.e. without any risk that the clients get 'stale file handle' events.
This likely
> would mean to use the same fsid but also that ganesha creates the same
file
> handles based on fsid and inode. We use NFS version 3 only.
>
> We do export the filesystems to whole subnets and it may become difficult
to
> find all clients in advance and to reboot shortly after the migration.
>
> Already the fsid part is puzzling, because ganesha uses two(!) uint64 values,
> where kernel nfsd on RHEL6 requires an integer. Probably the two uin64
map to
> a 32-hex-UUID (=16 byte, 128bit)
>
> Thank you,
>
> Heiner Billich
Ganesha file handle format is different from Linux knfsd (in fact Ganesha goes
to specific effort to prevent a knfsd handle from ever looking valid).
Yes, Ganesha has a mode where it uses the UUID in the file handle (it can have
different fsid modes also, that's just the default).
Frank