Re: DiskDevice API v2.1

On 2003-04-03 at 22:32:36 [-0800], Ingo Weinhold wrote:
> 
> Tyler Dauwalder <tyler-cyCl/[email protected]> wrote:
> > 
> > > > I am not sure if it's worth the effort to provide partition-
> > > > granular
> > > > locking - perhaps it's better to be able to add jobs to the
> > > > current
> > > > update task=3D3D3F AFAICT all partition changes have to be
> > > > sequential
> > > > anyway.
> > > 
> > > Changes to a single partition. Yes. But I actually don't see the
> > > reason
> > > for a sequence of changes to one partition. If requested by one
> > > application, it can as well be bundled to one action. And if the
> > > requests is issued by another application, it may operate with
> > > obsolete
> > > data anyway (imagine one app resizing the partition to occupy all
> > > free
> > > space, while the second one wants to move it) and should be
> > > forbidden.
> > > That's why I'd prefer a locking mechanism -- be it for individual
> > > partitions or for the whole device.
> > 
> > I think in general, the whole device will end up getting locked in
> > most
> > cases we'd have now, but with a partitioning system that supported
> > many
> > levels of hierarchy (and maybe even with intel extended partitions, 
> > I
> > don't know... Ingo=3F)
> 
> Yes, it should be fine, to lock an extended partition, if the logical
> partitions on it are going to be manipulated.
> 
> > one could get away with only locking a portion of
> > the drive during a task, and thus let the user muck around with the
> > rest of it if desired. So it might be useful to support fine grained
> > locking. However, is it worth the overhead (1 lock per partition)=3F
> 
> I think, non-blocking locking should be sufficient, or maybe even the
> better choice. Anyway, even if blocking only one semaphore per 
> actually
> waiting thread would be required. By accident I almost finished 
> writing
> a newsletter article on a quite similar locking problem during my off
> time. :-)
> 
> [...]
> > > > > > class BPartition {
> > > > > > public:
> > > > > >     BEmptySpace* EmptySpaceAt(int32 index) const;
> > > > > >
> > > > > > // I have resize and move separated because move could be
> > > > > > filesystem
> > > > > > // independent, whereas resize could not
> > > > > I hope, you're right regarding move. The absolute addressing
> > > > > you
> > > > > found in
> > > > > ISO9660 disk scares me a bit. Maybe we can ignore that.
> > > > 
> > > > Well, it depends on us if we want to support resizing/moving of
> > > > file
> > > > systems that require absolute block addressing. It would sure be
> > > > possible, but also much more complicated to do. Doing that 
> > > > online
> > > > (while the partition can still be accessed) might be very
> > > > complicated
> > > > (for both, the kernel and the file system).
> > > > The only file system that require this feature is iso9660 - and
> > > > there,
> > > > resizing/moving doesn't make any sense. But then, I don't have
> > > > any
> > > > idea
> > > > about UDF
> > 
> > UDF also uses absolute addresses per "volume" (i.e. physical 
> > medium).
> 
> *sigh*
> Those people don't learn. ;-)

Nope. :-) 

> > > > If
> > > > that
> > > > would require absolute blocks, we should go back to the drawing
> > > > board
> > > > :)
> > > 
> > > If UDF does, I would vote for omitting support for it out of
> > > principle
> > > (if necessary, locking Tyler into some basement without 
> > > computers).
> > > ;-)
> > 
> > :-P That's a really bad idea all around. :-)
> > 
> > Seriously, with no UDF support, you have no DVD support. And iso9660
> > is
> > no better, and we sure aren't dropping CD support. How about
> > BDiskSystem::UsesAbsoluteAddressing()=3F
> 
> Won't be needed, I think. BDiskSystem::SupportsMoving() could also be
> used for FSs.

I was thinking it would be needed to support a generic moving system 
for relatively addressed systems while still allowing each system to 
provide its own moving implementation.

-Tyler