Turning on NFSv4 - Impact to current V3 users?

Thanks for your comments Chris!

Reaching out to 350+ users is going to be a bit of a challenge.  In hindsight we should have supplied them with the mount syntax to use (using nfsvers=3) instead of just saying "Your new share is ready....blah.com:/blah-share".  Oh well

Speaking of, is there a best practices for client side mount options when using Isilon?   (We are running 8.0.0.4)  If we are going to reach out to the users to have them re-mount using version it would also be good to make sure they are using any other recommended options.

Also, is there an Isilon settings, perhaps a zone setting, that when a client mounts you can force it to use a specific version?

Thanks!

-Brian

Totally agree, that reaching out to that many users won't be a fun endeavor, however it's the only safe course of action, other than perhaps getting this v4 data it's own cluster, which if it's big enough maybe that's an option to mitigate risk.  No, there is no way to turn on/off v4 on a per-access-zone level.  It's global, which is why it's listed under global settings in the GUI.

For Client mount best practices, look here:

457328 : OneFS: Best practices for NFS client settings https://support.emc.com/kb/457328

~Chris

Thanks again Chris!

I had one of our customers run a test and when the client server mounted it as V4 it seem to appear and function as "normal" (ie...like they would see using V3).

There is the message of trying to mount V4.1 and failing and that might alarm a customer that is paying attention

TEST --> mount the share as V3 and write a file, look at permissions

(root)

# mount -t nfs -o nfsvers=3 xxx.xxx.xxx.xxx:/test2 /mnt/test2/

(jsmith)

% touch /mnt/test2/file

% ls -al /mnt/test2/

total 46

drwxr-xr-x. 2 jsmith smith-group    22 May 22 10:04 .

drwxr-xr-x. 4 root      root 4096 May 22 10:03 ..

-rw-r--r--. 1 jsmith smith-group 0 May 22 10:05 file

TEST --> now mount the share without specifying the version and see what happens, compare.

(root)

# mount -v  xxx.xxx.xxx.xxx:/test2 /mnt/test2/

mount.nfs: timeout set for Tue May 22 10:16:33 2018

mount.nfs: trying text-based options 'vers=4.1,addr=xxx.xxx.xxx.xxx,clientaddr=xxx.xxx.xxx.xxx'

mount.nfs: mount(2): Permission denied

mount.nfs: trying text-based options 'vers=4.0,addr=xxx.xxx.xxx.xxx,clientaddr=xxx.xxx.xxx.xxx'

(jsmith)

% touch /mnt/test2/file2

% ls -al /mnt/test2/

total 48

drwxr-xr-x. 2 jsmith smith-group    45 May 22 10:15 .

drwxr-xr-x. 4 root      root 4096 May 22 10:03 ..

-rw-r--r--. 1 jsmith smith-group    0 May 22 10:05 file

-rw-r--r--. 1 jsmith smith-group    0 May 22 10:15 file2

Keep in mind that v4 is a stateful protocol, while v3 is stateless.  That also has an impact on failover behavior.  Stateful protocols expect that the server maintains session state information, however if you use a dynamic smart connect zone and the IP fails over for some reason due to maintenance or a fault, the other node wouldn't know about the session state.  On Isilon, most stateful protocols, like SMB are recommended to be on static smart connect zones, where the IP doesn't move, it just goes down. The clientOS is smart enough to realize the IP is down, do a new nslookup, get a new IP, and reconnect.  Many NFS clients on even newer linux OS'es are that smart, or perhaps I should say mountd isn't that smart and they'll just make it a stale mount if you have NFSv4 on a static smart connect zone.  They use v3 style logic.  Anyway just something to be aware of.  The last I heard from someone on the unix protocols team the guidance was still to use dynamic for NFSv4, because better to failover and lose some session state information, versus failover and get a stale mount because the client isn't behaving properly.

Also make sure they mount with noacl if you want to keep using POSIX permissions only, and NFSv4 ACLs.

~Chris