Date: Wed, 10 Jul 2013 10:05:18 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Claude Buisson <clbuisson@orange.fr> Cc: rmacklem@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435 Message-ID: <51DD782E.7090503@FreeBSD.org> In-Reply-To: <51DD6777.90803@orange.fr> References: <51DD5451.2010801@orange.fr> <51DD6777.90803@orange.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello guys; Thank for finding this, however ... On 10.07.2013 08:53, Claude Buisson wrote: > On 07/10/2013 14:32, Claude Buisson wrote: >> Hi, >> >> Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to >> r253007, I >> have hit the following: >> >> claude@zorglub$ mount_nfs watson:/home /mnt >> claude@zorglub$ /bin/ls /mnt/ >> claude doc.old ports.old sysref >> distfiles obj portsperso xorg-dev >> doc ports src xtrafiles >> claude@zorglub$ /bin/ls /mnt/claude >> ls: /mnt/claude: Stale NFS file handle >> claude@zorglub$ /bin/ls /mnt/ports.old >> CHANGES UPDATING dns multimedia textproc >> COPYRIGHT accessibility editors net www >> ... >> >> some directories may be listed, for the others the result is "Stale >> NFS file handle" >> >> This exists for a 8.4-STABLE client system, for a 9.1-STABLE client >> system, and >> also with a local mount (localhost) on the server system itself. >> >> I checked with memsticks of official snapshots (to eliminate the >> influence of >> local patches and customized kernels), with the result: >> >> FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected >> >> FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected >> >> Doing a binary search on the kernel source (without any patch) lead >> to the >> "culprit": >> >> ---------------------------------------------------------------------- >> Author: pfg >> Date: Mon Jul 1 03:00:15 2013 >> New Revision: 252435 >> URL: http://svnweb.freebsd.org/changeset/base/252435 >> >> Log: >> Change i_gen in UFS to an unsigned type. >> >> In UFS, i_gen is a random generated value and there is not way for >> it to be negative. Actually, the value of i_gen is just used to >> match bit patterns and it is of not consequence if the values are >> signed or not. >> >> Following other filesystems, set it to unsigned and use it as such, >> >> Discussed by: mckusick >> Reviewed by: mckusick (previous version) >> MFC after: 4 weeks >> >> Modified: >> head/sys/ufs/ffs/ffs_vfsops.c >> head/sys/ufs/ufs/dinode.h >> head/sys/ufs/ufs/inode.h >> head/sys/ufs/ufs/ufs_extattr.c >> ---------------------------------------------------------------------- >> >> which is entirely UFS (not NFS) related. >> > > Reverting 252435 + 252437 and rebuilding the kernel seems to give back > a working > system. > > Claude Buisson > While I understand this change caused the issue and I am willing to revert it, I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I presume glusterfs) have unsigned i_gen. Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51DD782E.7090503>