migrate from kernel nfsd - can we do it transparent without client reboot/remount?
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 https://www.psi.ch
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
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@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
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@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
participants (3)
-
Billich Heinrich Rainer (PSI) -
Frank Filz -
Heiner.Billich＠psi.ch