Niall,
Niall Power wrote:
> Hi Sundar,
>
> On Wed, 2007-03-28 at 10:09 -0700, Sundar Yamunachari wrote:
>
>> Niall,
>>
>> Niall Power wrote:
>>
>>> More comments/questions after having spent more timing examining the
>>> disk layout modelling:)
>>>
>>> 4.1.1:
>>> The data model assumes that only one VTOC (DiskSlices_t) can exist
>>> on disk. On X86, the DiskSlice_t is associated with a parition. Will the
>>> assumption on X86 that only one partition can contain a VTOC hold true
>>> in the future? Will ZFS make this irrelevant?
>>>
>>> --------------------------------------------------------------------------------------
>>> typedef struct {
>>> char *diskName; /* Disk
>>> Name for look up */
>>> PartitionInfo_t pinfo[FD_NUMPART]; /* fdisk
>>> partitions */
>>> } DiskParts_t;
>>>
>>> How is the pinfo[FD_NUMPART] array ordered? Is it ordered by partition ID
>>> or by
>>> physical partition order on the disk?
>>>
>>>
>> The partitions are listed based on the partition id. Partition numbers
>> are set based on the order of creation.
>>
>>>
>>> --------------------------------------------------------------------------------------
>>> typedef struct {
>>> int partitionId; /* fdisk id (1-4) */
>>> int partitionOrder; /* Order in the disk */
>>> int partitionType; /* Solaris/linux swap/X86boot */
>>> om_content_type_t contentType; /* Solaris/Linux */
>>> long partitionSize; /* Size in GB */
>>> boolean_t active; /* Is the partition active */
>>>
>>> } PartitionInfo_t;
>>>
>>> There is no indication of of where the partition offset starts or ends on
>>> the disk. It forces us to
>>> assume that partition at order 0 begins at offset 0 and, partition at order
>>> 1 begins immediately
>>> after where partition at order 0 ends and so on. This seems like a
>>> dangerous assumption.
>>> We discussed this briefly during the work week and about how the GUI would
>>> handle it. I believe
>>> we said the GUI, due to it's design would not support it (it doesn't convey
>>> start and end points of
>>> partitions to the user) and so it would issue a warning and force a
>>> destructive repartitioning of the disk.
>>> But from the data modelling perspective, partition start and end offsets
>>> seem like important data to capture.
>>>
>>>
>> I was thinking of not exposing disk information like starting cylinder
>> and offset. I was hoping that we can get away by providing the
>> partitionOrder information. It looks like we need to provide starting
>> cylinder and offset. I will add this information and remove
>> partitionOrder from the PartitionInfo_t.
>>
>
> >From then GUI's perspective, we don't want to be dealing with intimate
> disk geometry details (Cylinders, heads, sectors etc.). Is there a way
> to represent the offset in MB just like partition sizes? Also, I don't
> think there is a conflict between parititionOrder and offset. Can we
> leave paritionOrder in, since it seems like a nice convenience to have?
>
I could convert the cylinder information to MBs. I will also keep the
partitionOrder information.
- Sundar
> Niall.
>
>
>> - Sundar
>>
>>> Thanks,
>>> Niall.
>>> --
>>> This message posted from opensolaris.org
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> caiman-discuss at opensolaris.org
>>> http://opensolaris.org/mailman/listinfo/caiman-discuss
>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20070328/75f74820/attachment.html>
