Date: Wed, 20 Jul 2005 09:16:37 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Paul Saab <ps@FreeBSD.org>, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs_socket.c Message-ID: <20050720091329.N50372@fledge.watson.org> In-Reply-To: <20050719202127.GU40423@elvis.mu.org> References: <200507180212.j6I2CHkP074749@repoman.freebsd.org> <20050718071812.GF46538@darkness.comp.waw.pl> <20050719202127.GU40423@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Jul 2005, Alfred Perlstein wrote: >> I saw ESTALE errors on NFS clients after rebooting NFS server. >> umount/mount was the only way to fix it. Your commit should fix my >> problem? My machines are running 5-STABLE. > > Unlikely, the source of such a problem is probably that the order of > mounted filesystems has changed and a different fsid was given to your > exported fs. > > One way to fix it is to make sure that your fses are mounted in the > right order each time. Or you can do a hack whereby exporting loads the > fsid from a persistent file in the filesystem. I've been wondering for a while about the best way to address this, and a possible start is to, on mount, attempt to derive the fsid from the uuid of the file system (if present). We would need to then detect collisions at run-time and fall back to an alternative fsid. The chances of a collision are fairly low, so it might be an improvement over current behavior. Dynamic minor numbers have further reduced the effectiveness of the fsid model, which had already been significant reduced by CAM. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050720091329.N50372>