Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

NFS V3 and files bigger than 2 G

Honored Contributor

NFS V3 and files bigger than 2 G

I want to know which version of Tcpip (assuming I have the last C RTL patch applied) allows NFS to deal with files bigger than 2 G

Re: NFS V3 and files bigger than 2 G


Since TCPIP V5.1 the NFS Server supports both NFSv2 and NFSv3 clients.

The NFS client, included with TCP/IP Services up till current version V5.4, uses the NFS Version 2 protocol only.

Esteemed Contributor

Re: NFS V3 and files bigger than 2 G

Take a look at the following datasheet


Ofcourse this is talking about a layered product called TCPware from process software. I have been using this for quite some time.

The following extract from that link above might be of importance to you

NFS client and server provides transparent and quick access to remote files and directories. New to TCPware 5.6 is a high performance NFS v3 server (RFC 1813). The NFS v3 server improves performance over the NFS v2 server by reducing the number of calls made between the client and server. File attributes are now returned during normal operations, therefore separate calls are no longer required. Other restrictions that have been eliminated in the NFS v3 server include the file storage size can exceed 2-gigabytes and data transfers can exceed 8 KB.

Security is enhanced with a new access permission procedure. This procedure ensures that no unauthorized client can gain access to a server's file objects. The NFS v3 server is flexible, supporting many of the NFS v2 and v3 clients on the market today.

Honored Contributor

Re: NFS V3 and files bigger than 2 G

Thanks Henk

The support of NFS V3 for the NFS client is expected for when ? Tcpip V5.5 ?
Rick Dyson
Valued Contributor

Re: NFS V3 and files bigger than 2 G

Be aware that the NFS client has a small memory leak that will catch you if you do LOTS of file operations (say, millions of files) reading, writing, renaming, etc. Eventually, the client locks up and the shutdown of TCPIP will fail, etc. So a reboot requires a manual 'finger push' reset. :)

NOTE: Once you get to that stage the only solution I have found is to reboot.

The workaround from engineering that I have is to dismount and remount the drive when it gets low on quotas... :) Of course, knowing when that will occur is not trivial! Once you get a handle on how often your use exhausts the client resources, just schedule a dismount/mount cycle before that time.