In message <200311252357.hAPNvlGs021309@agora.fsl.cs.sunysb.ed u>, Erez Zadok wr
ites:
>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.


Whether or not checkdirs() is retained, I think it is just good
practice to undo at unmount time anything that was done when the
filesystem was mounted. An obvious case is if you accidentally mount
a file system in the wrong place or make the common mistake of
typing "mount -a" when there are NFS entries in fstab that are
already mounted. Without the unmount-time checkdirs call, this is
an operation that cannot be undone because any processes that had
a cwd of the covered vnode before the mount will lose their cwd
entirely if you unmount it.

There were also some obscure cases involving booting frem CD and
then mounting the real root filesystem directly over /. If you
unmount it later, all processes would lose their fd_rdir references
to /, so they suddenly become chrooted into a dead vnode even though
their original root directory on the CD root still exists.

Anyway, I think the best solution for now is to make the checkdirs()
at unmount time conditional on the MNT_FORCE flag. This should fix
amd's EBUSY detection while still making it possible to fully undo
the effects of a mount operation. The change is fairly trivial, so
I'll see if I can get something committed before 5.2 is released.

Ian
_______________________________________________
freebsd-fs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"