[openbeosstorage] Re: DiskDevice API v2.1

"Axel D=F6rfler"  <axeld@xxxxxxxxxxxxxxxx> wrote:
> 
> 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=3D3F) 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)=3D
> > 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 can still decide that, when we have a clearer picture of the kernel 
part. Even later, for I don't think, it would be that hard to switch 
from device- to partition-based locking or vice versa.

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

We could add methods to BDiskDeviceRoster to provide support for that. 
The typical iteration methods (GetNextActiveJob(BDiskDeviceJob*), 
RewindActiveJobs()) and watching support (StartWatchingJobs(), 
StopWatchingJobs()). BDiskDeviceJob (or better name=3F) would feature 
methods for returning general information about the job, as well as its 
current progress.

>, which are already done, etc. - and that data must 
> survive a crash as well.

Your meta data partition sounds like a very good solution to that.

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

A bit of partition support for booting must be in the kernel, anyway. 
Or do I miss something=3F It would also be nice, if booting from logical 
partitions was supported.

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

:-)
Also -- even, if I'm nitpicking here -- most of the functionality would 
be in modules, not in the kernel itself. Not that this means anything 
for the stability of the system. ;-)

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

Right.

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

Exactly. Moreover, according to my current image, the userland add-ons 
would contain very little functionality, only the GUI code for editing 
the system-specific parameters. So, there is very little that needs to 
be consistent.

[...]
> > > > 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()=3D3F
> 
> Wait, wait! Sure, we can support UDF, but does its partitions have to 
> be resizable/movable=3D3F I don't think it would be too bad if those 
> file 
> systems are not supported by the advanced partition manager 
> functions.

Yes, it seems we all agree on that. :-)

> Or we could introduce the requirement to unmount those partitions 
> first.

I wonder anyway, how it can be done, while the FS is mounted. I mean, 
even node IDs may change during resizing. I don't know the inner 
workings of the VFS, but at least applications holding a node=5Fref or an 
entry=5Fref (among them the Tracker, I suppose) may end up being very 
confused.

> > > > > > // large/small enough for initialization with a given 
> > > > > > system=3D3D3D3F
> > > > > > 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=3D3D3D5Finitialize() 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=3D3D5Finitialze() 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=3D5Fcheck=3D5Fpartition=3D5Flimits(off=3D5Ft offset, off=3D5Ft size);
> 
> in the FS API=3D3F Would that be enough=3D3F

All the BDiskSystem hooks should have counterparts in the FS API. There 
could also be one function that processes them all, like 
fs=5Fvalidate=5Foperation(uint32 operation, void *parameters).

> > > > > 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=3D3D3D3F
> > > You mean that e.g. BPartition::Move() would be ommitted in favor 
> > > of 
> > > a
> > > BDiskSystem::Move(BPartition*,...)=3D3D3F
> > > 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.

It shouldn't be too hard to implemented it like that.

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

If we really limit the userland add-ons to provide only the GUI for the 
system-specific parameters -- for intel partitions that would be the 
partition type and the `active' flag -- then the add-on won't be needed 
before the parameters are actually going to be displayed/edited.

We could even dynamically load/unload the add-ons. This means the add-
on has to be reloaded with every request of a parameter editor, but, 
since those add-ons won't be that huge, this will be reasonably fast 
(not that quick for laptop users, when the HD is turned off at that 
moment, though).

CU, Ingo

Other related posts: