From owner-freebsd-fs@FreeBSD.ORG Tue Nov 25 15:58: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 0B4DB16A4CE for ; Tue, 25 Nov 2003 15:58:00 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB8A743F75 for ; Tue, 25 Nov 2003 15:57:58 -0800 (PST) (envelope-from ezk@fsl.cs.sunysb.edu) Received: from agora.fsl.cs.sunysb.edu (IDENT:YREcBNQLJcxYLWN5xNGmmOApwO5syPLM@agora.fsl.cs.sunysb.edu [130.245.126.12])hAPNvbHn032392; Tue, 25 Nov 2003 18:57:37 -0500 Received: from agora.fsl.cs.sunysb.edu (IDENT:Tzbi/6YTV7V/aCD1Ai3EmmDzjzsaIhqo@localhost.localdomain [127.0.0.1]) hAPNvlg9021313; Tue, 25 Nov 2003 18:57:47 -0500 Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.12.8/8.12.8/Submit) id hAPNvlGs021309; Tue, 25 Nov 2003 18:57:47 -0500 Date: Tue, 25 Nov 2003 18:57:47 -0500 Message-Id: <200311252357.hAPNvlGs021309@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: Ian Dowse In-reply-to: Your message of "Tue, 25 Nov 2003 23:38:44 GMT." <200311252338.aa05451@salmon.maths.tcd.ie> X-MailKey: Erez_Zadok cc: amd-dev@cs.columbia.edu cc: Erez Zadok 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: Tue, 25 Nov 2003 23:58:00 -0000 In message <200311252338.aa05451@salmon.maths.tcd.ie>, Ian Dowse writes: > In message <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.edu>, Erez Zadok wr > ites: > >Hmmm, yes I think that could be a serious problem (esp. since fbsd doesn't > >have autofs yet). And I think it deviates from "norms" where a cwd is > >essentially occupying a vnode within the mounted f/s and therefore the f/s > >shouldn't be unmounted! This is rather bad for users who sit on an nfs mnt > >point, ls'ing files happily, and then the kernel unmounts the mnt pt, moves > >their cwd down to the covered (typically empty) vnode, and the poor user's > >next /bin/ls shows nothing. > > Yes, I agree completely - however the question of what to do with > references to about-to-be-covered vnodes at mount time still remains. > I'll have to look in more detail at why the checkdirs() approach > was needed in the first place to see if simply removing it is an > option. If you have a cwd on a lower mnt pt before the mount, I'd say it makes _some_ sense to move it "up" to the mnt pt (root vnode) of the newly mounted fs. This could be very useful for, say, a login shell. I say "some" b/c I'm concerned about the possibility that some bad process (rm -rf) that is just started in an emoty mnt point, all of sudden is moved up to a vnode full of real files, and that process may happily go on to delete the files in the newly mounted f/s. Doing the reverse upon unmount (moving the cwd from upper to lower) sounds even stranger to me. Why? B/c the process used to see some files and now it sees none. Where did it all go? This can break applications in all sorts of unhappy ways. > Any other approaches I can think of right now for solving this issue > appear to either extend the original checkdirs() hack, or else just > replace one kind of undesirable behaviour with another. My personal philosophy when it comes to a choice b/t several un/desirable modes of operations is the following: 1. Offer flags/options/whatever for users to pick their desired behavior. 2. Don't break existing "expected" behavior: make that the default mode of operation. 3. In some cases, it's desirable to change the default behavior to one of the "new modes". But at least everyone will have a way to get the behavior they want. 4. Disadvantage: poor programmers/maintainers have to keep several modes of operation working. The above won't make everyone happy, but it'd maximize the percentage of happy users. > Ian I guess we first need to find out what were the original reasons for the change in fbsd. Maybe we can find a way to accommodate the needs for that change w/o breaking functionality. Cheers, Erez.