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