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

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> > 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=3D3F 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?) 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)?

> > We just should limit the number of jobs a single partition has
> > outstanding (i.e. only one resize change, one movie, etc.).
> 
> If requested by a single application, this application should bundle
> the changes anyway and commit them together. There would never be more
> than one active or pending job per device or partition.

Yes. Multiple changes can be batched, but only one set of modifications 
may be going at any time.

> 
> > The way I think of partition updating for R2 is that the real work 
> > is
> > done by a userland app - the kernel will just have to be updated
> > about
> > the current state, it would then maintain its internal translation
> > map
> > so that the system will continue to work during those changes. That
> > translation map will also be written to disk (logged), so that the 
> > on
> > -
> > disk representation can always be translated correctly.
> > The boot script could check for any outstanding partition changes 
> > and
> > run the DriveSetup utility if necessary.
> >
> > To cut a long story short - I still think it makes sense to provide
> > complete userland add-ons to implement the functionality found in 
> > the
> > different partitioning systems.
> 
> Oh, that is new. Well, in fact it is old, viz. exactly as in R5. I
> thought we were agreeing, that a separation of concerns makes sense.
> I.e. the kernel modules/add-ons would implement the complete read and
> write access, while the userland add-ons merely provide functionality
> needed for the GUI.

That's what I thought, too. :-)

> I actually don't see the benefit of keeping the write support out of
> the kernel. It seems even more natural to me to let the kernel do all
> the business, instead of having a userland application notify it about
> the progress -- that's an unnecessary dependency IMO.

I agree.

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

> > (BTW what's the relation with Mount Rainier if any=3D3F). 

I don't think there is any (but I'm not *that* familiar with it 
either). I believe Mount Ranier is simply a packet writing standard 
that moves enough of the messiness (like defect management) into the 
hardware. The result is that the interface becomes clean enough for it 
to be easily incorporated in the regular OS filesystem interfaces, and 
you can thus treat optical media more like a normal random access 
device (assuming you also use a filesystem designed for that, like UDF).

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

> > > >     bool CanResize() const;
> > > >     bool CanMove() const;
> > > >     status=3D5Ft ValidateResize(off=3D5Ft*) const;
> > > >     status=3D5Ft ValidateMove(off=3D5Ft*) const;
> > > >     status=3D5Ft Resize(off=3D5Ft);
> > > >     status=3D5Ft Move(off=3D5Ft);
> > > >
> > > >     bool CanEditParameters() const;
> > > >     status=3D5Ft GetParameterEditor(
> > > >            BDiskScannerParameterEditor **editor,
> > > >            BDiskScannerParameterEditor **parentEditor);
> > > >
> > > > // Perhaps we should have something for checking a partition is
> > > > // large/small enough for initialization with a given 
> > > > system=3D3F
> > > > The
> > > > // parameter editor could alternately check for this.
> > > I would just add another method in BDiskSystem.
> > 
> > We could just add another file system error code for the
> > fs=3D5Finitialize() function.
> 
> That's too late. In DriveSetup the GUI element for selecting the 
> system
> shall only show the feasible options. So, it must be known before
> fs=5Finitialze() is called.

Yes.

> > > > class BDiskSystem {
> > > > public:
> > > >     bool SupportsParentSystem(const char *system) const;
> > > >         // True in most cases. NULL =3D3D=3D3D raw device.
> > > >     bool SupportsChildSystem(const char *system) const;
> > > >         // False for most file systems, true for most 
> > > >         partitioning
> > > >         // systems.
> > > >
> > > >     bool IsPartitioningSystem() const;
> > > >     bool IsFileSystem() const;
> > > > };
> > > As said above, I would make them virtual. Moreover, the Supports*
> > > System()
> > > should also have a BPartition* parameter. Otherwise partitioning
> > > systems
> > > that allow only a limited number of levels can't give an
> > > authoritative
> > > answer here. The BPartition* parameter could optionally be NULL to
> > > ask
> > > whether it is supported in general.
> > 
> > I think there should be read-only set of classes, and an additional
> > add
> > -on based set to actually do any changes. This will be only rarely
> > used, so it probably doesn't make much sense to clobber the general
> > API
> > with it - so I like something BDiskSystem (as a virtual (and
> > abstract)
> > base class), but it should contain everything, and not only the 
> > check
> > operations.
> > Thoughts=3D3F
> 
> You mean that e.g. BPartition::Move() would be ommitted in favor of a
> BDiskSystem::Move(BPartition*,...)=3F
> Mmh, that doesn't sound very convenient.

No, I don't think I like that either.

-Tyler