This is a discussion on Re: vnode refcnt bug? - FreeBSD ; In message , Ian Dowse writes: > In message , 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 ...
In message <firstname.lastname@example.org>, Ian Dowse writes:
> In message <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.ed u>, Erez Zadok wr
> >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
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
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
The above won't make everyone happy, but it'd maximize the percentage of
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.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"