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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> Here's v2.3 of the DiskDevice API proposal. I hope and believe it 
> contains all the changes we discussed, but I may have overlooked 
> something in the flood of early April emails we had. :-)
> 
> http://www.dauwalder.net/DiskDeviceAPI_v2.3.zip
> 
> Here are a couple of notes/questions:
> 
> - For indicating whether a partition supports a given operation while 
> still mounted, do you prefer "bool *whileMounted" or "bool 
> *requiresUnmounting"? I've used the former because it's easier to 
> type. :-)

Fair enough. :-)

> - I left the parameters parameter in ValidateCreateChild() in case 
> the child parameters somehow affect the min/max size of the potential 
> child.

Makes sense.
BTW, something feels wrong with the last parameter of 
BPartition::CreateChild(): `**BPartition child'.
Mmh, I can't get hold of what that could be. ;-)

> -     int32 CommitModifications(bool synchronously = true,
>               BMessenger progressMessenger = BMessenger(),
>               bool receiveCompleteProgressUpdates = true,
>               BMessage *template = NULL);
> still exists in BDiskDevice. We kind of talked about this previously, 
> but I was never really convinced we came to a decision. I'm only kind 
> of comfortable moving it into BPartition. Opinions?
> 
> - I haven't done anything about BPartitionableSpace vs. 
> BPartitioningInfo, as that's still on the table. 

It seems we have the following alternatives:

1) Leave it as it is. That has the drawbacks, that the information 
would be stored in the BPartition hierarchy being of no interest to the 
user, and requiring some amount of updates, when BPartitions are 
Resize()d or Move()d.

2) Introduce a BPartition::GetPartitionableSpaceAt(int32, off_t*, off_t
*), which would
a) return a data stored in the BPartition object
b) retrieve the info from the kernel
Whereas a) has the same drawbacks as 1) (minus that it does use an 
extra object). b) introduces overhead due to the syscall required per 
invocation. Moreover the partition might change between two calls, 
which probably renders the information invalid. One could simply make 
it a requirement that the partition is locked, though.

3) Introduce a BPartitioningInfo with a similar method and a 
BPartition::GetPartitioningInfo() to get it. Similar to 2 b), with less 
syscalls though (one per GetPartitioningInfo()).

4) Drop the whole partitionable space idea.

2 b) and 3) would be my favorites.

CU, Ingo