Parted (all versions but testing was done with parted-3.1-5 and pyparted used was pyparted-3.8-5) This is something that was reported before by Dennis Gilmore #697125 but was automatically closed out when fc15 OEL'd What I've found is that it appears to depend on the disk hardware and that you're running on something other than x86_64 (I ran the same test on a x86_86 with a SATA SSD which came back with same values) In this test setup I have a sparc64 running 2 drives one is a traditional SAS hard drive and the other is a SAS SSD [root@sparc64 ~]# lsscsi [0:0:0:0] disk HITACHI H106060SDSUN600G A2B0 /dev/sda [0:0:1:0] disk ATA INTEL SSDSA2BZ10 0362 /dev/sdb First off the traditional HD: ----------------------------- >>> import parted >>> sda = parted.Device(path="/dev/sda") >>> disk = parted.Disk(device=sda) >>> print sda.biosGeometry (72961, 255, 63) >>> print disk.partitionAlignment parted.Alignment instance -- offset: 0 grainSize: 1 PedAlignment: <_ped.Alignment object at 0xfffff80107e28850> >>> print sda.optimumAlignment parted.Alignment instance -- offset: 0 grainSize: 2048 PedAlignment: <_ped.Alignment object at 0xfffff80107e28910> >>> print sda.minimumAlignment parted.Alignment instance -- offset: 0 grainSize: 1 PedAlignment: <_ped.Alignment object at 0xfffff80107e28850> >>> print sda.optimumAlignment.intersect(disk.partitionAlignment) parted.Alignment instance -- offset: 0 grainSize: 2048 PedAlignment: <_ped.Alignment object at 0xfffff80107e28a10> ----------------------------- Ok this is great, exactly what you'd expect Now then,.. lets try the same with the SAS SSD: ----------------------------------------------- >>> 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> ----------------------------------------------- Anaconda has a field day with this and suddenly you cannot align partitions by anything less than 16Gb (well, 15.8Gb to be exact) Please feel free to reassign to pyparted if you fell that would the better place for this Thanks Phil =--=
I should also mention that this seems unique to sun labelled disks
I tried replicating this on a USB pendrive (on both x86_64 and sparc64) but that works correctly 8/
After a bit of thinking and some mucking around with numbers,.. ---------------------------------------------------------------- Expert command (m for help): p Disk /dev/sda (Sun disk label): 255 heads, 63 sectors, 5400 rpm 9729 cylinders, 0 alternate cylinders, 9729 physical cylinders 0 extra sects/cyl, interleave 1:1 Label ID: GNU Parted Custom cyl 9729 alt 0 hd 255 sec 63 Volume ID: Units = cylinders of 16065 * 512 bytes Device Flag Start End Blocks Id System /dev/sda1 0 2048 16450560 1 Boot /dev/sda2 2048 8192 49351680 8e Linux LVM /dev/sda3 0 9729 78148192+ 5 Whole disk ---------------------------------------------------------------- Since the SMI label binds it's partition alignment by *cylinder* not sector 16065 isn't as unexpected as I first thought. 16065 * optimum (2048 sect) = 32901120 bytes 32901120 * 512 / (1024*1024) = 16065.00 MB or 15.68Gb Still, that is a massive partition alignment. 8/ It may be better to use minimum alignment which would work out a bit better 16065 * minimum (1 sect) = 16065 sect = 8225280 bytes 8225280 * 512 / (1024*1024) = 7.844... MB (one cylinder) It may not be optimum but it is far more sensible and prevents situations where you can have up to 15Gb of disk not usable The alternative to this mess if perhaps to use EFI. Not all sparcs can use EFI though 8/ GPT is also an option although firmware to support it as a system boot disk isn't available yet. I'll refer to https://blogs.oracle.com/dlutz/entry/partition_alignment_guidelines_for_unified Ideas/thoughts? Phil =--=
Forest and trees,.. This is looking more and more like an off by one issue but I cannot pinpoint WHEN it happens,.. certain disks partition up in 2MB chunks, others in 15Gb slices 12161, 255, 63 = 32901120 ... totally WRONG 72961, 255, 63 = 2048 ... isn't this wrong though? Sun label is supposed to be by cylinder boundary ie (256*64*sect size = usually 8Mb/64Mb (512/4096 depending on drive) I dunno what is going on exactly but I need confirmation that Sun labels are aligned by cylinder boundary Even then I dunno if this is libparted going wrong or pyparted. Phil =--=
Gah,.. I didn't explain that too well When querying a drive >>> print disk.partitionAlignment parted.Alignment instance -- offset: 0 grainSize: 16065 What we seem to be getting back is the result of the BIOS heads/sectors directly multiplied without accounting for head 0 or sector 0 ie 255 x 63 = 16065 instead of 256 x 64 = 16384 ------------------------------------------------------- In the case of >>> print sdb.optimumAlignment.intersect(disk.partitionAlignment) parted.Alignment instance -- offset: 0 grainSize: 32901120 This value seems to be the result of the Least common multiple of 16065 and >>> print sdb.optimumAlignment parted.Alignment instance -- offset: 0 grainSize: 2048 And I suspect even that is wrong as the Sun label would normally be cylinder aligned so I'd have expected that to be 16384 ------------------------------------------------------- As I say,.. I dunno if this is pyparted's fault or libparted's fault. I'm also making the assumption that the partitioning is CYLINDER aligned Phil =--=
Never mind,.. I've been really .. *REALLY* stupid. I made an assumtion that 63 sectors 0-63 which would be 64 sectors which is why all my math never worked out correctly, it's *REALLY* 0-62 sectors or 63 sectors a track. I am now enlightend and feel bloody silly. At the same time it transpires that the anaconda alignment code I was reading was doing something really weird by trying to align on both the cylinder boundary and the MiB which is why it was passing around 15.8Gb chunks. I've corrected the anaconda alignment code to use cylinder alignment when using sun disk label. Again, apologies for my neophyte error Phil =--=
*** Bug 860747 has been marked as a duplicate of this bug. ***