[openbeosstorage] Re: To Unmount Or Not To Unmount

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 
(correct? I've forgotten how fine the locking granularity is when you prep 
modifications, but I think it's by device isn't it?). Furthermore, once 
Commit() has been called, aren't the partitions of interest locked until 
all the jobs that affect them are completed? 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. 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.

> Moreover it would be less
> convenient, if one just wants to unmount a partition and has to
> PrepareModifications(), Unmount(), CommitModifications(); which BTW won't
> work, if someone else is already preparing modifications.
 
I don't think it really needs to be terribly convenient, though, do you? 
We're basically servicing mount(), unmount(), Tracker, and DriveSetup, 
right? 

> It's even more complicated for Mount(). It can't be done immediately, when
> you invoke it on a modified or even new partition.

Yes, it certainly needs to be part of the job queue in that case.

> 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.

> 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. 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. 

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?

-Tyler

Other related posts: