FreeLists / openbeosstorage / [openbeosstorage] Re: My Usual Confusion

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Fri, 13 Jun 2003 21:37:01 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
> > I just want to make sure, that I'm not running into a totally wrong
> > direction. Here's a small example for illustration: Given a hard 
> > disk
> > containing one extended intel partition containing one logical
> > partition being BFS formatted, the object hierarchy should look 
> > like
> > this:
> > 
> > BDiskDevice:
> > Type():        "Hard Disk Media"
> > ContentType(): "Intel Partition Map"
> > 
> > contains:
> > 
> > BPartition:
> > Type():        "Intel Extended Partition"
> > ContentType(): "Intel Extended Partition" ???
> > 
> > contains:
> > 
> > BPartition:
> > Type():        "Intel Logical Partition"
> > ContentType(): "BFS Filesystem"
> > 
> > True, or shall the content type of the extended partition be 
> > something
> > different?
> 
> Hmmm. Yes, true, I guess, using the Type()+ContentType() system. 
> That's 
> messier than I had anticipated...
> 
> As I'll mention below, I think the ContentType()-only system does a 
> much nicer (and equally effective) job:
> 
> BDiskDevice:
> DeviceType():  "Hard Disk Media"
> ContentType(): "Intel Partition Map"
>  
> contains:
> 
> BPartition:
> ContentType(): "Intel Extended"
>  
> contains:
> 
> BPartition:
> ContentType(): "BFS Filesystem"

Looks better.

> > Assuming that I'm more or less right, is there really a one to one
> > correspondence of types and disk systems, as I assumed until a few
> > minutes ago? IIRC, that was the idea for the BDiskSystems -- it was
> > intended that using Supports{Child,Parent}System() DriveSetup could
> > offer a choice child partitions of what types can be created on a
> > partition -- but somehow this concept hasn't made it into 
> > BPartition:
> > 
> > status_t CreateChild(off_t start, off_t size, const char *
> > parameters,
> > BPartition** child = NULL);
> > 
> > Neither a type nor disk system can be specified. 
> 
> No, the idea here was that child partitions would always be 
> unformatted 
> and empty, and initialization would then specify a type.

That's what I thought, too. Though, I obviously had another notion of 
`partition' in mind. Like contiguous space of a certain size located at 
a certain position. Initialization would only affect this space.

> E.g., to add 
> an extended partition, one would create an empty partition, then 
> initialize it to the type `intel extended partition', which would 
> only 
> be allowed if the parent were of type `intel partition map'. Further, 
> if one initialized said partition to any other type, it would 
> automatically become a primary partition instead. (I guess, 
> technically 
> speaking, you'd probably internally make it an unformatted primary 
> partition by default, and upon initialization to `intel extended', 
> you 
> would convert it to an extended partition).

I see.

> > If that is no 
> > mistake,
> > it can only mean, that the `parameters' shall contain the 
> > information
> > about the partition type to be created. This makes quite a bit of
> > sense, since the disk system for (the content of) a partition 
> > should
> > know very well, child partitions of which types can be created on 
> > it
> > (e.g. primary or extended partitions on an intel partition map hard
> > drive, or only logical partitions on an extended one).
> 
> To tell you the truth, I don't remember what `parameters' is for. :-) 

It may very well have been proposed by me. :-)
The parameters will specify... err... parameters for the disk system. 
In case of a file system, those may be block size, support for optional 
features (e.g. default indices), and the like.

> If one wanted to be able to specify the type of child partition at 
> creation time, certainly that would be the way to do it. I think I 
> preferred the idea of simply creating an empty partition and then 
> letting the partitioning system decide at initialization time exactly 
> what type it would be.

The problem I see here is, that the parent partitioning system (also) 
has to take action, when the child partition is initialized. More 
precisly, the parent system has to know, what to do for a certain child 
disk system. The advantage is, that we would get consistency between 
the type specified in the partition descriptor and the type of the 
system the partition actually contains.

[...]
> > What seems to be intended for BPartition and what IMHO also makes 
> > most
> > sense, is that a partition has a parent-given type and it can be
> > formatted with any disk system. Which therefore corresponds to the
> > ContentType(). When creating a child partition, the parent assigns 
> > a
> > type to the child, but its contents will be uninitialized until
> > initialized with a disk system. Hence there is a ContentType() - 
> > disk
> > system correspondence, but Type() is just a type string.
> 
> Yes, but that being the case, the parent-given type is really of no 
> useful relevance (other than purely academic), as far as I can see. 
> Disk systems don't care if they're being used on a primary partition 
> or 
> a logical partition. And one can decide if a partition is a primary 
> or 
> logical partition simply by examining the parent type and seeing if 
> it 
> is intel or intel extended respectively. This is why I originally had 
> only Type() (which corresponded to our current ContentType()). 
> 
> The only argument I can think of for really needing our current 
> Type() 
> method is if we had a partitioning system that allowed the creation 
> of 
> different types of non-partitionable child partitions (i.e. two 
> different types of intel primary style partitions). But I can't think 
> of any good reason why such a feature would be offered. Further, I 
> would guess/hope that in most cases, one could implicitly determine 
> which of the types should be chosen, similar to the way primary vs. 
> extended can be implicitly chosen. 

As a matter of fact the intel partitioning scheme knows three extended 
and dozens of primary partition types. So, it is indeed a not 
completely trivial task to pick the right type given a child disk 
system. Since, as I believe, more or less all partitioning systems 
provide an identifier for the content type of a partition, something 
similar has to be done for all partitioning system modules.

[...]
> > To fix the problems, basically the concerned partition needs to be
> > supplied as well:
> > 
> >     bool SupportsChildSystem(KPartition *child, const char *system)
> > const;
> >     bool SupportsParentSystem(KPartition *child, const char *
> > system)
> > const;
> > 
> > `child' would be the partition, which shall be initialized with a 
> > disk
> > system, `system' the respectively other disk system. Instead we 
> > could
> > as well drop both methods, since BPartition::CanInitialize() can as
> > well have both conditions checked in the kernel. Or we also 
> > introduce 
> > a
> > BDiskSystem::CanInitialize(BPartition*).
> > 
> > IsSubSystemFor() should still be OK, I think.
> > 
> > Thoughts?
> 
> Well, the question intended to be answered by the the 
> SupportsXYZSystem() functions is not whether one can create a 
> partition 
> of a given type, but whether one can initialize an already existing 
> child partition with the given disk system. The two functions 
> together 
> would be used to implement BPartition::CanInitialize(). I suppose the 
> extra KPartition argument could still be useful, though. 
>
> Btw, shouldn't it be `bool SupportsChildSystem(KPartition *parent, 
> const char *system) const;' instead?.

Then the important information, which child partition is meant, is not 
provided. Suppose we want to allow only one extended partition (which 
isn't an uncommon constraint), (re-)initializing the already existing 
extended partition should succeed, while it should fail for all other 
partitions.

> Given my original intention to support empty child creation only, 
> what 
> then is really missing is something like:
> 
> bool SupportsCreateChild(KPartition *parent);

Well, ValidateCreateChild() could be used, but maybe a dedicated 
function would be better.

> So, the question, I guess, comes down to how we want to specify the 
> typing of child partitions from the parent partition's point of view. 
> My original intent was to do this implicitly. As mentioned, if done 
> this way, the current Type() member is just a type string that tells 
> the user some potentially interesting, but otherwise not particularly 
> useful information. And it has no correlation to disk systems.

Right.

> The other way to do it would be to allow specification of the 
> partition 
> Type() at creation time, which means some more supporting code,

I wouldn't bet on that. The magic to be implemented to support the 
implicit typing might turn out to be rather complex. If I would be 
forced to guess, I'd say even quite a bit more complex than what would 
be needed for the other approach.

> and 
> also a way to pass Type() values around.

We pass so many things around, I don't think one more does matter that 
much. :-)

> I don't like that idea, unless 
> you have some compelling arguments otherwise. I don't really think we 
> need it, and don't currently think we'd gain anything by going that 
> route.

I have at least some arguments to be evaluated.

1) As mentioned above, the parent disk system will be involved (and the 
parent partition modified), when a child is being initialized. The 
parent system must known all possible child types. Not only child disk 
systems, but child types. The different flavors of FAT for instance 
result in different intel partition types, while there's probably only 
one FAT file system module. I'm afraid, that means analyzing the 
initialization parameters for the child disk system, which I don't like 
that much. KDiskSystem::ValidateInitialize() could get an optional 
parameter, through which the corresponding type is returned. Then this 
type could be passed to the parent system instead.

2) Implementation-wise things would be less uniform, since the 
partitioning system would have to apply changes to the parent shadow 
partition on an initialization request from userland.

3) Wouldn't DriveSetup be less convenient and/or powerful? I suspect, 
it won't be possible to e.g. create a ReiserFS partition, but don't 
initialize it (the add-on may be read-only anyway). This is even a bit 
inconsistent, since in the intel case the newly created partition will 
have a certain type (unless there's a value for `undefined', which I 
haven't seen till now). We could consequently force the user to always 
initialize a newly created partition, but this would obviously be more 
restrictive.

> As to Type() and ContentType() specifically, I'm also no longer 
> convinced that Type() is all that necessary. I'd just as soon get rid 
> of it and rename ContentType() back to Type().

I see no problem with that.

> > PS: How about a BPartition::GetDiskSystem(BDiskSystem*)? Then
> > BPartition::ContentType() wouldn't even need to have any strong
> > relationship with the disk system's (pretty) name.
> 
> Having seen the way types would need to laid down using the 
> Type()/ContentType() system, I'd actually much rather just go back to 
> using Type() only (semantically like our current ContentType()) than 
> do 
> this. Though a GetDiskSystem() call could still be useful.

I think, there is a difference between the disk system's pretty name 
and the partition's type. E.g. we have several flavors of FAT, but only 
one FS module handling all.

CU, Ingo