[openbeosstorage] Re: To Unmount Or Not To Unmount

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?

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

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 :-)

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

Indeed, but convenience wouldn't hurt either :)
(but I am okay with that as well)

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

I think so, yes.

> > 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. Which would kinda be the 
job of mount()/unmount().
But I think it's often (for the user) more appropriate to fail the 
mounting process in that moment (as Tyler suggested, methinks).

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

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

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

What would we gain because of the latter?`

Bye,
   Axel.

Other related posts: