This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 851194 - Parted has problems with Sun disk label
Parted has problems with Sun disk label
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
18
sparc64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
: 860747 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-23 09:23 EDT by Bryce
Modified: 2012-11-01 22:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-01 21:33:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bryce 2012-08-23 09:23:12 EDT
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
=--=
Comment 1 Bryce 2012-08-23 14:57:28 EDT
I should also mention that this seems unique to sun labelled disks
Comment 2 Bryce 2012-08-23 16:45:13 EDT
I tried replicating this on a USB pendrive (on both x86_64 and sparc64)  but that works correctly 8/
Comment 3 Bryce 2012-08-28 07:39:10 EDT
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
=--=
Comment 4 Bryce 2012-10-30 10:53:22 EDT
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
=--=
Comment 5 Bryce 2012-10-30 11:09:15 EDT
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
=--=
Comment 6 Bryce 2012-11-01 21:33:05 EDT
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
=--=
Comment 7 Bryce 2012-11-01 22:07:18 EDT
*** Bug 860747 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.