From owner-freebsd-current Tue Jul 25 02:53:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id CAA18865 for current-outgoing; Tue, 25 Jul 1995 02:53:21 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id CAA18858 for ; Tue, 25 Jul 1995 02:53:19 -0700 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id CAA27120 for ; Tue, 25 Jul 1995 02:52:41 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id KAA01160; Tue, 25 Jul 1995 10:36:43 +0100 Date: Tue, 25 Jul 1995 10:36:42 +0100 (BST) From: Doug Rabson To: current@freefall.cdrom.com, Joerg Wunsch cc: current@freefall.cdrom.com Subject: Re: Interesting NFS problem with -current In-Reply-To: <199507241058.MAA05269@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Mon, 24 Jul 1995, J Wunsch wrote: > As Jordan K. Hubbard wrote: > > > > Scenario: Several hosts with cross-mount privs managed by AMD. Host foo > > exports its cdrom drive to host bar, which can see it in /host/foo/cdrom. > > So far, so good. Now say that foo unmounts the CD in the drive and mounts > > a new one. Host bar now sees: > > > > : /host/foo/cdrom: Stale NFS file handle > > > > In response to any access to the newly mounted CD. At the > > same time as the access, host foo prints: > > > > fhtovp: file start miss 60 vs 20 > > > > On its system console. > > > > I figure this is something to do with NFS v3, but perhaps the data > > is of use to someone working in that area. > > The decision of the cd9660 code whether some NFS client is accessing a > stale NFS file handle (i.e. one that's been granted for a previous CD) > is rather a crock. I haven't got a good idea on how to solve this > better. > > I suspect the generation of stale NFS file handles for removable > sd-type disks might be as broken as well, but it's not as obvious > there as for CDs. Might become a point with the advent of ZIP drives > however. The mount-time could be added to the filehandle (someone suggested this to me as a possible readdir cookie verifier for cd9660). That would certainly detect disk-changes but it would also invalidate filehandles for the same disk which was mounted twice. Hmm. No this wouldn't work because if the server rebooted, then all the clients would lose. What we need is a unique signature for the disk. What about an MD5 checksum for the first few hundred blocks? -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939