From owner-cvs-all@FreeBSD.ORG Wed Jul 20 08:16:21 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E44C16A41F; Wed, 20 Jul 2005 08:16:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE2AF43D48; Wed, 20 Jul 2005 08:16:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6535546B2A; Wed, 20 Jul 2005 04:16:20 -0400 (EDT) Date: Wed, 20 Jul 2005 09:16:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20050719202127.GU40423@elvis.mu.org> Message-ID: <20050720091329.N50372@fledge.watson.org> References: <200507180212.j6I2CHkP074749@repoman.freebsd.org> <20050718071812.GF46538@darkness.comp.waw.pl> <20050719202127.GU40423@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Saab , src-committers@FreeBSD.org, Pawel Jakub Dawidek , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs_socket.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 08:16:21 -0000 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