From owner-freebsd-fs@FreeBSD.ORG Tue Nov 25 21:00:00 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E51216A4CE for ; Tue, 25 Nov 2003 21:00:00 -0800 (PST) Received: from Daffy.timing.com (mx2.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD3B43FBF for ; Tue, 25 Nov 2003 20:59:58 -0800 (PST) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id hAQ4xjpB036497; Tue, 25 Nov 2003 21:59:45 -0700 (MST) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.12.6p3/8.12.6) with ESMTP id hAQ4xfjh074733; Tue, 25 Nov 2003 21:59:41 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.12.6p3/8.12.6/Submit) id hAQ4xfRw074730; Tue, 25 Nov 2003 21:59:41 -0700 (MST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16324.13117.190129.769195@gromit.timing.com> Date: Tue, 25 Nov 2003 21:59:41 -0700 X-Mailer: VM 7.17 under Emacs 21.1.1 From: John E Hein To: Erez Zadok In-Reply-To: <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.edu> References: <200311252107.aa96370@salmon.maths.tcd.ie> <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.edu> X-Spam-Status: No, hits=-15.6 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_VM version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: amd-dev@cs.columbia.edu cc: Ian Dowse cc: fs@freebsd.org Subject: Re: vnode refcnt bug? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 05:00:00 -0000 Erez Zadok wrote at 16:22 -0500 on Nov 25: > Ian, I'm CC-ing my reply to the am-utils developers mailing list, amd-dev. > Let's keep this thread on both fs@ and amd-dev for a bit. > > Can the people on amd-dev who noticed this problem please answer Ian's > questions? > > In message <200311252107.aa96370@salmon.maths.tcd.ie>, Ian Dowse writes: > > In message <200311252003.hAPK3Bb9017036@agora.fsl.cs.sunysb.edu>, Erez Zadok wr > > ites: > > >Please see this short thread of discussion on amd-dev. I've included two > > >messages from this thread. It suggests that fbsd5 may have a vnode refcount > > >bug (a vnode isn't held where it should). > > > > > >I've not personally investigated this bug. Does anyone on fs@ has come > > >across such a possible bug? > > > > Hmm, I guess it is caused by checkdirs() in vfs_mount.c moving the > > process cwd to the underlying vnode before attempting the unmount. > > Does this only happen if the cwd is at the mount point itself? Yes. It appears that's the case. I can force it to happen with amq -u. > > When a file system is first mounted, checkdirs() looks for processes > > that had a cwd or chroot set to the vnode that is about to be > > covered. It moves these processes to the new mountpoint vnode. > > This behaviour goes back a long time (I'm not sure what the reasons > > were), but it had the problem that you would get a "Device busy" > > error if you attempted to unmount the file system later, and a > > forced unmount would leave the process with a stale cwd or chroot > > vnode (i.e. "mount /mnt; umount /mnt" would fail if any processes > > previously had a cwd of /mnt, and "mount /mnt; umount -f /mnt" would > > cause such processes to lose their reference to the /mnt directory). No forced umount is necessary. It just gets unmounted after the amd timeout if you just sit at your shell prompt and wait (or amq -u). > > The reference count checks could be moved to before checkdirs(), > > but I think there are cases where the current behaviour is preferable, > > so maybe it needs to be an unmount() flag... BTW, does amd delete > > the mountpoint directory after the unmount? That would explain why > > the directory goes away entirely. > > If Amd created the mount point when it started (say, the mnt pt didn't > exist), then Amd will also try to rmdir it upon unmount. It gets unmounted first. Then within a minute, it gets deleted. ls returns nothing (but exit code is 0). pwd gives: pwd: .: No such file or directory