On Wed, 7 Jun 2000, Alexander Viro wrote:
> On Wed, 7 Jun 2000, James Sutherland wrote:
>
> > > A) suppose we have a bunch of filesystems union-mounted on
> > > /foo/bar. We do chdir("/foo/bar"), what should become busy? Variants:
> > > mountpoint, first element, last element, all of them.
> >
> > The key question, presumably, is which FSs can we unmount from the union
> > without /foo/bar breaking? If all the FSs can be unmounted safely, none
> > should be busy.
>
> There is only one tricky situation: when we umount everything but the last
> element (and thus union-mount degenerates into the plain mount) && there
> is something standing on the mountpoint && aside of that mounted fs is not
> busy. Then current code will refuse to umount the thing, but the new one
> (for consistency) probably ought to (see the (E)). Yes, we can umount
> anything without breakage.
In which case, nothing should be busy. "busy" <=> "something breaks if
unmounted". The mount point itself should be busy, though, I think -
eliminating a mount point with something mounted on would break things, I
presume?
> > > Doing replace (i.e. if everything can be umounted - do it and mount
> > > the new fs in place of the union) is attractive - we probably might
> > > treat the normal mount same way, which kills the "I've clicked in my
> > > point'n'drool krapplication ten times and it mounted CD ten times,
> > > waaaaaah" bug reports.
> >
> > Making the point'n'drool krapplication fail the second time it tries to
> > mount anything makes more sense, IMO - that way, however much the user
> > points and/or drools, they only have one thing mounted. (Ideally, the
>
> Erm... In the case of "replacement" semantics it would go
>
> <first point&drool> mounted /dev/cdrom on /cdrom
> <next point&drool> woops, already mounted something? umount and put /dev/cdrom
> on that (/cdrom) place. We are back to the same situation.
> ad infinitum...
I'd prefer:
mount /dev/cdrom on /cdrom ==> succeeds
mount /dev/cdrom on /cdrom ==> fails - /cdrom is busy
> [sweet memories of printer asking to insert paper, seventy identical
> ~30-page turds produced by TeX in the queue, very unhappy little Sun
> holding said queue and very annoyed luser sitting in 3 feet from printer
> and keeping fornic^Wclick on "print"...]
WinNT servers deal with that much more efficiently. The OS will repeatedly
submit the job to the queue anyway, leaving the luser free to go on and
break something else... :)
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:28 EST