[openbeosstorage] Re: To Unmount Or Not To Unmount

On 2003-09-23 at 14:09:44 [-0700], Ingo Weinhold wrote:
> 
> On 2003-09-23 at 20:38:24 [+0200], Axel Dörfler wrote:
> > Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > On 2003-09-22 at 13:24:33 [-0700], Ingo Weinhold wrote:
> > > > In favor of unmounting on commit speaks, that the behavior would be
> > > > consistent with the other modifying methods. On the other hand,
> > > > mounting/unmounting can be done by a third party at any time, even
> > > > if one
> > > > is preparing modifications at that time.
> > > I thought we were going to serialize all mounting and unmounting
> > > through
> > > the ddm. Thus, the system unmount() call ought to work via ddm calls,
> > > which
> > > means (assuming we use "on commit" semantics) that unmount() will
> > > simply
> > > fail if someone is preparing modifications on a given partition's
> > > device
> > 
> > That's what I thought, too... that's what the integration with the VFS
> > is all about, right?
> 
> I should clarify the situations that can occur:
> 
> 1) Partition is busy: There are scheduled or already executing jobs, that
> affect the partition. Jobs are scheduled, when
> BDiskDevice::CommitModifications() is invoked.
> 
> 2) A user has invoked BDiskDevice::PrepareModifications() (started a
> transaction, to use that term) but not yet called
> BDiskDevice::{Cancel,Commit}Modifications() (rolled back respectively
> committed the transaction).
> a) Mount()/Unmount() is invoked on a BPartition object belonging to the
> very same BDiskDevice object.
> b) Mount()/Unmount() is invoked on a BPartition object belonging to another
> user (but of course referring to the same partition).
> c) mount()/unmount() is invoked for the partition.
> 
> There's no further distinction of cases for 1), because in any case, the
> same must happen: mount(), unmount(), Mount(), Unmount() must fail, for
> otherwise we'd risk, that something bad will happen, if the mount state
> changes behind the back of a job that operates on that partition.
> 
> What shall happen in the case 2)a)-c) was subject of my mail. :-)

I really did understand that, even if it perhaps didn't seem like it. :-) 
When you said, "On the other hand, mounting/unmounting can be done by a 
third party at any time, even if one is preparing modifications at that 
time", it just sounded as though you were implying a call to mount() or 
unmount() could go and do things behind the back of the ddm. That being 
said, having the cases enumerated is useful. :-)

> > > Furthermore,
> > > once Commit() has been called, aren't the partitions of interest locked
> > > until all the jobs that affect them are completed?
> 
> Not locked, but marked busy. That is you can still read/write lock them (in
> the kernel), but certain operations on it shall fail, namely preparing new
> modifications for them (more precisely: PrepareModifications() will work
> fine, but any operation that would affect a busy partition will fail), and
> mounting/unmounting.

Okay.

> > > This seems like an
> > > (almost :-) reasonable restriction to me: once you start planning a set
> > > of jobs that involve a partition, you can't mount/unmount it until you
> > > cancel or no more
> > > jobs remain that affect that partition.
> 
> Please don't mix that up. Until you commit the changes you're in the
> situation 2) (and there aren't any jobs yet), that is, in principle,
> there'd be no problem with mounting/unmounting immediately. At least from
> the DDM point of view.

No, I wasn't mixed up (at least, I don't think I was :-). I was saying it 
would seem reasonable to me to disallow mounting and unmounting anything on 
a device from the time PrepareModifications() was called on a device until 
no shadow partitions were left for it, and then disallow mounting and 
unmounting any busy partitions as long as they were still marked busy, just 
as is implied by the suggestion below that Mount() and Unmount() call 
PrepareModifications() on their own as needed.

> > > We could add an appropriate
> > > error
> > > code so we could give a reasonable error message in Tracker and
> > > mount()/unmount(), suggesting that "The partition is locked, perhaps
> > > you're
> > > mucking around with things in DriveSetup?" similar to the busy
> > > message you
> > > get when you try to unmount a CD you're currently playing in
> > > SoundPlay. The
> > > only problem I see with this so far is that it does seems better to
> > > allow a
> > > partition to be unmounted even if jobs are being prepared for it, but
> > > perhaps this would be justification for a hybrid approach with
> > > Unmount() as
> > > addressed below.
> > 
> > Not sure about that - the jobs in question should know about the drive
> > status; I could imagine that their operation is different when the disk
> > is mounted vs. unmounted.
> > Maybe we should think about that deeply, first, too :-)
> 
> Well, as far as the jobs go, there are no choices. As soon as they are
> created, the partitions that are going to be affected are marked busy and
> mounting/unmounting and modification requests must fail.
> That point is, that the jobs are only created when the modifications are
> committed. Until then, we are free to mount/unmount would-be affected
> partitions.

I think his point was that, for example, whoever is responsible for resizing 
the bfs partition is likely going to want to know whether the partition is 
mounted or not, assuming resizing while mounted is supported.

> [...]
> > > > So, perhaps a hybrid approach is the best solution: When one has
> > > > already
> > > > called PrepareModifications() on the device, the Mount() and
> > > > Unmount()
> > > > invocations will take effect after the modifications are committed,
> > > > otherwise the mounting/unmounting is done immediately.
> > > >
> > > > Mmh, maybe that's confusing? It would make the mount/unmount
> > > > handling in
> > > > the disk device manager a bit more complicated, but as far as I can
> > > > judge
> > > > it at the moment, it should be feasible.
> > > I don't like the hybrid in general. I think I would rather see
> > > Mount() and
> > > Unmount() follow the rules like everybody else. For Mount() at least,
> > > I
> > > don't see any gain in making it work in two different ways. For
> > > Unmount(),
> > > though, perhaps the hybrid approach would be worth the effort, just
> > > to
> > > allow a partition to be unmounted even if jobs are being prepared for
> > > it.
> > 
> > Is it really hybrid? It sounds like Mount()/Unmount() would just call
> > PrepareModifications() if needed themselves.
> 
> I didn't think of that. That would also be where the synchronous
> CommitModifications() mode would come handy... in case anyone still
> remembers the discussion about that. ;-)

I'd forgotten, but I remember now. :-)

> The drawback of that approach -- if one considers it one -- is that one
> cannot mount/unmount a partition when another app is preparing
> modifications for the same disk device.
> 
> > > > Oh, there's still the general question whether the user has to
> > > > Unmount()
> > > > the concerned partition explicitely, when e.g. CanResize()
> > > > reported, that
> > > > it works only when the partition is unmounted, or whether Resize()
> > > > would
> > > > automagically do the unmounting (or at least mark the partition to
> > > > be
> > > > unmounted).
> > > Perhaps an unmount call should just be placed in from of the
> > > offending job
> > > in the job queue when it's built.
> 
> What I was thinking of, was, that when a job gets executed, it would itself
> first invoke the respective Validate*() hooks of the disk system again and
> learn, if the disk system needs a currently mounted partition unmounted, or
> if something's fishy and it should rather fail on the spot.
> 
> So, if it realizes that the partition is mounted, but the disk system can
> only operate on it when unmounted, it could either a) unmount the partition
> or b) fail. 

Or c) block and request that the user either unmount the partition or 
cancel. Or d) block and warn the user that when they click "unmount", the 
partition will be promptly unmounted, thus they should close anything from 
that partition that they currently have open (or risk losing data) or else 
click "cancel" to cancel the job queue. 

> The problem with a) is, that it's a bit beyond the control of
> the user. If, as Axel says, unmounting would always work not heeding
> pending vnodes, then the user might risk losing data, I suppose.

I agree, that's a bit mean to pull the rug out from under the user like 
that. b) seems like a weak solution, too, though. c) and d) seem nicer to 
me. Is there any reason you can think of why either couldn't be made to work?

> > > Of course, if the user if playing
> > > MP3s or
> > > whatever off the partition at the time, we'd need a way to notify the
> > > user
> > > to stop using the partition so it may be unmounted for processing.
> > 
> > That won't be necessary - the VFS will be able to unmount partitions at
> > any time; open descriptors won't prevent that any longer, they will
> > just be invalidated - and since that's the only connection to the file
> > anyway...
> 
> Cool feature. :-)
> It must be used with care, I believe, for one gambles with the user's data.

Yeah, it does seem a bit sketchy.

> > > So, to sum up, I think I would prefer to use "on commit" semantics
> > > and try
> > > and get the rest of the system to work reasonably and logically
> > > within the
> > > normal DiskDevice job framework, with perhaps the exception of
> > > allowing
> > > hybrid semantics with Unmount() to allow unmounting while jobs are
> > > being
> > > prepped. What do you think?
> 
> I don't really like having different semantics for Mount() and Unmount().
> Either both should have the hybrid semantics or neither one should.

Fine.

> > What would we gain because of the latter?`
> 
> Obviously that one can unmount a partition, while another app is preparing
> modifications for the same disk device (mind you, it doesn't even need to
> be the same partition, nor does it play a role whether any changes have
> been made at all, yet).
> 
> Just to throw another alternative onto the pitch: The Mount()/Unmount()
> methods could have a boolean parameter indicating whether the operation
> shall be carried out immediately or being queued. Not sure, if that makes
> any sense in case of Mount(), though. Usually invoking the modifying
> methods on a BPartition object indeed immediately changes the object.
> That's a bit complicated for Mount(), since one can't get a valid dev_t
> until the partition is really mounted.
> 
> So, maybe only a `bool immediately = true' parameter for Unmount(), while
> Mount() would always work immediately and fail, if the partition was
> modified?

That sounds okay to me. So, mounting would fail if the partition in question 
is busy. Immediate unmounting would fail is the partition is busy, but 
queued unmounting would be part of the job queue and thus succeed always. 
Correct?

-Tyler

Other related posts: