[parted-devel] Trying to figure out whats going wrong with sun disk label (off by one?)

[Bryce]

I'm trying to figure out where this test case below goes horribly wrong.
I'm NOT a python debugging person so I've no idea whats happening under
the hood in terms of hooks/api calls. Basically I'm getting wild values
for alignment sizing (Sun disk label)

    >>> sdb = parted.Device(path="/dev/sdb")
    >>> disk = parted.Disk(device=sdb)
    >>> print sdb.biosGeometry
    (12161, 255, 63)
    >>> print disk.partitionAlignment
    parted.Alignment instance --
      offset: 0  grainSize: 16065
      PedAlignment: <_ped.Alignment object at 0xfffff80107e28910>
    >>> print sdb.optimumAlignment
    parted.Alignment instance --
      offset: 0  grainSize: 2048
      PedAlignment: <_ped.Alignment object at 0xfffff80107e28a90>
    >>> print sdb.minimumAlignment
    parted.Alignment instance --
      offset: 0  grainSize: 1
      PedAlignment: <_ped.Alignment object at 0xfffff80107e28910>
    >>> print sdb.optimumAlignment.intersect(disk.partitionAlignment)
    parted.Alignment instance --
      offset: 0  grainSize: 32901120
      PedAlignment: <_ped.Alignment object at 0xfffff80107e28b90>
      



Partition alignment seems to be set for cylinder boundry's so sectors *
heads (255 * 63 = 16065 but is this not wrong since sector and head 0
exist so the math should work out as 256*64 = 16384 instead? or am I the
victim of lack of sleep? (technically I guess LBA drives logically don't
give a damn)

Similarly the python call to
optimumAlignment.intersect(disk.partitionAlignment) is WAAAAAAAY out of
whack being some weird 15.68 *GB* interval, which seems to be the
cylinder boundry * 2048. What the correct math for that should be I'm
unclear on. I think the code is trying to find the least common multiple
which would spilt out that value. If so the LCM would be 16384 (16Mb) 
which would be significantly more sane. I'd just like to confirm that
this is the source of the wild values I'm getting and that fixing the
math would fix the issue so that I'm not trashing some other
consideration I'm being ignorant of.

Phil
=--=



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20121030/a5dfa7c0/attachment.html>