FreeLists / openbeosstorage / [openbeosstorage] Re: DiskDevice API v2.1

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> 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. ;-)

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

[...]

CU, Ingo