Re: [RFC] union-mount stuff

[James Sutherland]

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.