NFS version 4 and 3


Version 3 maintains persistent locks. When a file system is unshared and shared back the locks are not destroyed so the state remains the same as if nothing has changed. Version 4 removes any state once the file system is unshared. All the state information is removed and any attempt to access the file again once shared back results in I/O error. The state does not change if it was unshared for some share option changes.
Pseudo file system name space is maintained in version 4. In version 3 clients must request for individual mount of the entire exported share. Version 4 client gets a seamless view of all the exported file system. Path traversal was not allowed in version 3.

Version 4 supports volatile file handles apart from persistent file handle. Server generates a unique file handle to every file. The file handle will change if the file is deleted and replaced by another file however will remain the same if server reboots or file was renamed. In oracle version 4 client connecting to non-oracle version 4 servers, volatile file handle must be used. Lease time is associated with every volatile file handle once the lease expires either the client has to request for a new file handle. Server caches the mapping between persistent and the volatile file handle. The file handle may change due to variety of different reasons like server reboot, file name rename etc.

Client recovery in version 4. The protocol is state full so that both the client and the server maintain the state of the open files and file locks. If the server reboots, client helps in getting the server back to the state where it rebooted by sharing the last state full information with the server. During the recovery phase any file open request are suspended. If any attempt is made the server responds back with GRACE signal allowing the client to wait for the grace amount of time before retrying the operation.

OPEN share support in version 4, where the client can specify either DENY_NONE/READ/WRITE/BOTH for other clients.

Delegation in version 4. Both client and server support delegation. Client never request for delegation, it’s the server which delegates read or write operation to particular client based on the access pattern. This reduces the traffic as most of the operation is delegated on the client end the server is not contacted back and forth for different operations. In case of conflict there are multiple ways to resolve the conflict, e.g is write operation is delegated to server A and the server B opens the file for write, NFS server removes delegation from A. Delegation is tested with eth client before granting. The nfs4cbd daemon uses dynamic port numbers and embeds inside the NFS version 4 packet so it cannot work across NAT and firewall.

UDP and TCP negotiations: The priority is given to the NFS protocol over the transport protocol. NFS version 3 uses UDP but the first available connection oriented protocol is TCP but the priority is given to UDP.

Comments

Post a Comment

Popular posts from this blog

zpool and power path partial compatibility

Is power path fully supported with zpools, no. It's partial. You can have the pseudo devices assigned to a pool but it uses the native ctd disk only. Recently I lost 2 paths from the vnx array to m9000 server running Solaris 11.1. When I ran the zpool status -x command some of the pools were online while some of them were un available. Power path was reporting 2 paths only but it was active. So ideally the zpools should be online. But it's not. I enabled the remaining 2 paths and all became online. Internally the pools were pointing to one of the ctd devices that belonged to dead path and it was not coming online. Also few of the emcpower devices were renamed, so I had to do zpool import -d with the alternate disk. It seems power path is not completely supported now but may become in future.
Read more

Recoverpoint replication reporting with vmax splitter

Guys, Have you ever thought of automating the RP replication status and send status via email or post it to any reporting platform. Since the splitter impacts the VMAX FA's and there is an overhead of 13% on the utilization its good idea to see if the replication is driving the utilization of vmax FA. There are ways of pulling iops/read/write using symstat but its utilization (Director CPU utilization etc) which plays a significant role. As it crosses 80% we start seeing the increase in device response time. However, to measure FA utilization we will have to go through SMAS UI then pull out the reports. Its manual effort. But there is a way to automate it through REST API. You can get the details what type of objects are supported by pointing to : https://smc server :8443/univmax/restapi Coming to the point, getting recoverpoint consistency group status fully automated doesn't seems to be tough. Lets get through the steps. 1. Hash your SSH keys of the unix host to ...
Read more

Weird problem post power maintenance, no Powerpath pseudo name for Luns

We had the scheduled power maintenance activity in our data center. Every team was notified and we powered doen the servers through cron job. The servers were powered down first then storage (CX-380). And the reverse was followed during startup. After the power shutdown, the SAN was booted up. we forgot to disable the the snapshots. They were still active. Once it came up, the sessions were not there, but snapshot was active. Tried to deactivate the snapshot, failed with the error the "Failing Command: K10SnapCopyAdmin DBid 0 Op 1051. 71 00 80 43" Tried to create a session and attach the snapshot to the session, still unable to deactivate it, neither was able to attach to any other session. Looked at powerlink: It says the command issued to the snapshot is not owned by the SP. I trespassed all the snapshot source lun to SPA, and then tried to deactivate, nothing happened. Rebooted the SP's one by one through the management console. (http:/SP-IP/setup) Then I was able to...
Read more