*sigh*
The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has *never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes > 32bit (not sure if that's signed, or unsigned, but....).
The answer was to either create, or find an unneeded directory with a < 32bit inode, rename the high-number inode, move the new directory to that name and location, move everything that was under the old high-inode dir to under the new, low-number inode dir with the correct name, and reexport; I restarted nfs for good measure, and all is right with the world (well, after I restarted autofs and nfslock on the clients).
mark
On Wed, Nov 04, 2015 at 12:59:14PM -0500, m.roth@5-cent.us wrote:
The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has *never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes > 32bit (not sure if that's signed, or unsigned, but....).
Out of curiosity, was this a 32-bit or 64-bit CentOS6 system?
Jonathan Billings wrote:
On Wed, Nov 04, 2015 at 12:59:14PM -0500, m.roth@5-cent.us wrote:
The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has *never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes > 32bit (not sure if that's signed, or unsigned, but....).
Out of curiosity, was this a 32-bit or 64-bit CentOS6 system?
We got rid of our last 32-bit servers years ago.
mark
On Wed, November 4, 2015 11:59 am, m.roth@5-cent.us wrote:
*sigh*
The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has *never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes > 32bit (not sure if that's signed, or unsigned, but....).
Mark, are you sure your XFS is mounted with " -o inode64" option? If not, then this whole thing maybe just in XFS itself. No need to do anything, just try to remount XFS with "-o inode64" option and see if the trouble goes. Sorry if that is what you had had from the very beginning, I seem to totally have missed this thread.
Valeri
The answer was to either create, or find an unneeded directory with a < 32bit inode, rename the high-number inode, move the new directory to that name and location, move everything that was under the old high-inode dir to under the new, low-number inode dir with the correct name, and reexport; I restarted nfs for good measure, and all is right with the world (well, after I restarted autofs and nfslock on the clients).
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Wed, November 4, 2015 11:59 am, m.roth@5-cent.us wrote:
The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has *never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes
32bit (not sure if that's signed, or unsigned, but....).
Mark, are you sure your XFS is mounted with " -o inode64" option? If not,
Yup. Got bit by that a year or two ago. On the NFS server, it's got inode64 in fstab. <snip> mark
On 11/4/2015 9:59 AM, m.roth@5-cent.us wrote:
*sigh*
The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has*never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes > 32bit (not sure if that's signed, or unsigned, but....).
I don't think this problem is specific to EL, I think its generic to NFS on Linux.
The answer was to either create, or find an unneeded directory with a < 32bit inode, rename the high-number inode, move the new directory to that name and location, move everything that was under the old high-inode dir to under the new, low-number inode dir with the correct name, and reexport; I restarted nfs for good measure, and all is right with the world (well, after I restarted autofs and nfslock on the clients).
a simpler fix is to number your nfs exports via option fsid=# where # is a unique-to-that-filesystem integer in /etc/exports... then you don't have to dance around
-
John R Pierce -
Jonathan Billings -
m.roth＠5-cent.us -
Valeri Galtsev