Date: Tue, 25 Nov 2003 18:57:47 -0500 From: Erez Zadok <ezk@cs.sunysb.edu> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: fs@freebsd.org Subject: Re: vnode refcnt bug? Message-ID: <200311252357.hAPNvlGs021309@agora.fsl.cs.sunysb.edu> In-Reply-To: Your message of "Tue, 25 Nov 2003 23:38:44 GMT." <200311252338.aa05451@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311252357.hAPNvlGs021309>