*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 at 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 <billings at negate.org>
On Wed, November 4, 2015 11:59 am, m.roth at 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 at 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 ++++++++++++++++++++++++++++++++++++++++
Jonathan Billings wrote:> On Wed, Nov 04, 2015 at 12:59:14PM -0500, m.roth at 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
Valeri Galtsev wrote:> On Wed, November 4, 2015 11:59 am, m.roth at 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 at 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, recycling bits in santa cruz