[openbeosstorage] Re: To Unmount Or Not To Unmount
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 23 Sep 2003 11:22:53 -0700
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:
