We're experiencing problems with some legacy software when it comes to NFS access. Even though files are visible in a terminal and can be accessed with standard shell tools and vi, this software typically complains that the files are empty or not syntactically correct.
The NFS filesystems in question are 8TB+ XFS filesystems mounted with "delaylog,inode64,logbsize=32k,logdev=/dev/sda2,nobarrier,quota" options, and I suspect that inode64 may have to do with the observed behaviour. The server is running CentOS 6.3 + all patches.
The clients exhibiting the problem are running CentOS 5.4 and CentOS 5.8 x84_64. Interesting enough, the application (which is available in 32-bit only) appears to work fine on RHEL3 32-bit; we have no CentOS5 32-bit systems to test.
I was wondering if anyone has seen such behaviour and whether it can be corrected using nfs mount options. The only other solution I have at the moment is reformatting to ext4, i.e. ugly.
On 10/09/2012 02:16 PM, lhecking@users.sourceforge.net wrote:
The clients exhibiting the problem are running CentOS 5.4 and CentOS 5.8 x84_64.
Which NFS protocol version?
Have you tried NFS mount with vers=3 ?
Mogens
Mogens Kjaer writes:
On 10/09/2012 02:16 PM, lhecking@users.sourceforge.net wrote:
The clients exhibiting the problem are running CentOS 5.4 and CentOS 5.8 x84_64.
Which NFS protocol version?
Have you tried NFS mount with vers=3 ?
From /proc:
nfs rw,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=<SERVER> 0 0
lhecking@users.sourceforge.net wrote:
We're experiencing problems with some legacy software when it comes to NFS access. Even though files are visible in a terminal and can be accessed with standard shell tools and vi, this software typically complains that the files are empty or not syntactically correct.
The NFS filesystems in question are 8TB+ XFS filesystems mounted with "delaylog,inode64,logbsize=32k,logdev=/dev/sda2,nobarrier,quota" options, and I suspect that inode64 may have to do with the observed behaviour. The server is running CentOS 6.3 + all patches.
The clients exhibiting the problem are running CentOS 5.4 and CentOS 5.8 x84_64. Interesting enough, the application (which is available in 32-bit only) appears to work fine on RHEL3 32-bit; we have no CentOS5 32-bit systems to test.
I was wondering if anyone has seen such behaviour and whether it can be corrected using nfs mount options. The only other solution I have at the moment is reformatting to ext4, i.e. ugly.
I would suspect the inode64 option is the problem
We had similar issues running 32 bit apps on a 64 bit clients accessing 'large' NFS servers (non-Linux NFS servers) - the 'fix' was to make sure the file systems were exported/mounted with 32 bit inode compatibility
I believe in our case the 32 bit apps in question were not compiled with large file support (they are/were 3rd party apps). I think if they were compiled with large file support, then they would work OK.
James Pearson
I would suspect the inode64 option is the problem
We had similar issues running 32 bit apps on a 64 bit clients accessing 'large' NFS servers (non-Linux NFS servers) - the 'fix' was to make sure the file systems were exported/mounted with 32 bit inode compatibility
http://xfs.org/index.php/XFS_FAQ#Q:_Why_doesn.27t_NFS-exporting_subdirectori...
Link colour in my browser indicates I've looked at this before. D'oh.
The fsid option seems to work, but I need more testing.
lhecking@users.sourceforge.net writes:
I would suspect the inode64 option is the problem
We had similar issues running 32 bit apps on a 64 bit clients accessing 'large' NFS servers (non-Linux NFS servers) - the 'fix' was to make sure the file systems were exported/mounted with 32 bit inode compatibility
http://xfs.org/index.php/XFS_FAQ#Q:_Why_doesn.27t_NFS-exporting_subdirectori...
Link colour in my browser indicates I've looked at this before. D'oh.
The fsid option seems to work, but I need more testing.
It did not work. The test environemnt was set up wrong.
lhecking@users.sourceforge.net wrote:
lhecking@users.sourceforge.net writes:
I would suspect the inode64 option is the problem
We had similar issues running 32 bit apps on a 64 bit clients accessing 'large' NFS servers (non-Linux NFS servers) - the 'fix' was to make sure the file systems were exported/mounted with 32 bit inode compatibility
http://xfs.org/index.php/XFS_FAQ#Q:_Why_doesn.27t_NFS-exporting_subdirectori...
Link colour in my browser indicates I've looked at this before. D'oh.
The fsid option seems to work, but I need more testing.
It did not work. The test environemnt was set up wrong.
Is it possible to re-build the 32 bit application with large file support?
James Pearson
lhecking@users.sourceforge.net wrote:
It did not work. The test environemnt was set up wrong.
Is it possible to re-build the 32 bit application with large file support?
Nope.
I guess you might be out of luck?
I'm not sure you can safely mount an XFS file system without inode64 that was previously mounted with inode64 - but I've never used inode64, so don't take my word on it ...
James Pearson
-
James Pearson -
lhecking＠users.sourceforge.net -
Mogens Kjaer