<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
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)<br>
<blockquote>
  <pre class="bz_comment_text" id="comment_text_0"><span class="quote">>>> sdb = parted.Device(path="/dev/sdb")
>>> disk = parted.Disk(device=sdb)
>>> print sdb.biosGeometry</span>
(12161, 255, 63)
<span class="quote">>>> print disk.partitionAlignment</span>
parted.Alignment instance --
  offset: 0  grainSize: 16065
  PedAlignment: <_ped.Alignment object at 0xfffff80107e28910>
<span class="quote">>>> print sdb.optimumAlignment</span>
parted.Alignment instance --
  offset: 0  grainSize: 2048
  PedAlignment: <_ped.Alignment object at 0xfffff80107e28a90>
<span class="quote">>>> print sdb.minimumAlignment</span>
parted.Alignment instance --
  offset: 0  grainSize: 1
  PedAlignment: <_ped.Alignment object at 0xfffff80107e28910>
<span class="quote">>>> print sdb.optimumAlignment.intersect(disk.partitionAlignment)</span>
parted.Alignment instance --
  offset: 0  grainSize: 32901120
  PedAlignment: <_ped.Alignment object at 0xfffff80107e28b90>
  </pre>
</blockquote>
<br>
<br>
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)<br>
<br>
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.<br>
<br>
Phil<br>
=--=<br>
<br>
<br>
<br>
</body>
</html>