9:45 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)
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