[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 04 Apr 2003 02:17:52 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> 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) 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 dunno - if it's easy to implement, then I would say why not. It can
only add to the number of features :)
> > > 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.
Okay, that seemed to be a stupid idea :)
But we should make sure that the user can see which tasks still have to
be carried out, which are already done, etc. - and that data must
survive a crash as well.
[write support in add-ons only]
> > > 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
No, it wouldn't be the same as in R5 - the kernel couldn't recognize
partitions at all.
> > 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.
Hm, maybe it was a bit too much of a good thing (a small kernel :-).
Now, when I think about it, the amount of work that has to be done by
the partition modules itself is pretty small. The data move routines
doesn't have to be changed for that at all.
So I almost agree with you - the only problem I see is that both
modules (the kernel and the userland add-on) must be consistent; the
kernel module must implement the features the userland add-on promises.
That doesn't seem to be too much of a hassle, though.
> > > 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).
Oh :)
> > > (BTW what's the relation with Mount Rainier if any=3D3D3F).
> 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).
Okay, I haven't looked at it in detail yet :-)
> > > 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
Wait, wait! Sure, we can support UDF, but does its partitions have to
be resizable/movable=3F I don't think it would be too bad if those file
systems are not supported by the advanced partition manager functions.
Or we could introduce the requirement to unmount those partitions
first.
> > > > > // large/small enough for initialization with a given
> > > > > system=3D3D3F
> > > > > 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=3D3D5Finitialize() 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=3D5Finitialze() is called.
> Yes.
Okay, that makes sense :-)
But then, there should be an explanation somewhere that those greyed
out file systems can't be installed on the partitions because they are
likely to be too small.
How about
fs=5Fcheck=5Fpartition=5Flimits(off=5Ft offset, off=5Ft size);
in the FS API=3F Would that be enough=3F
> > > > 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=3D3D3F
> > You mean that e.g. BPartition::Move() would be ommitted in favor of
> > a
> > BDiskSystem::Move(BPartition*,...)=3D3F
> > Mmh, that doesn't sound very convenient.
> No, I don't think I like that either.
It might not be convenient, but it would reduce the memory overhead of
applications using the API. Unless the add-ons are only loaded when the
app uses one of the partition type dependent functions the first time.
I wouldn't like if the system has to load all partition add-ons for
Tracker, even if they are not going to be used at all. And that
separation could be made stronger with an extra class that combines all
calls that would cause the add-on to be loaded.
Adios...
Axel.
Other related posts:
