With modern disk devices the concept of heads and cylinders does not map to the physical geometry of the hard disk device.

Part of the problem is that MSDOS partition table provides only limited space to store then number of heads and cylinders, which results in the commonly seen values of 255 heads, and 63 sectors per track.  With this limitation, there is no longer a performance advantage to try to align partitions to these "fake" CHS values.  In fact you might even experience worse performance by trying use cylinder alignment.

See:
https://en.wikipedia.org/wiki/Cylinder-head-sector

Due to the above limitations Cylinder-Head-Sector (CHS) addressing has been surpassed by Logical Block Addressing (LBA).

See:
https://en.wikipedia.org/wiki/Logical_block_addressing

Legacy operating systems, such as DOS, require compliance to the antiquated cylinder alignment boundaries.  As such many tools still support aligning to these fictitious cylinder boundaries.  The path forward as chosen by many operating system vendors is to use MiB alignment.

As such I am marking this bug as INVALID since cylinder alignment is a work of fiction with modern disk devices.

Hi Ron,

Since it appears that your reply was not posted to this bug report, I have copied your response into this post.

For reference, the original thread in the GParted forum can be found at the following link:

New partition size & alignment problems/issues
http://gparted-forum.surf4.info/viewtopic.php?id=16808

Responses follow below.


On 13-03-11 02:00 PM, Ronald F. Guilmette wrote:
>
> I was and am already well aware of the fact that for modern drives, CHS
> no longer relates in any meaningful way to the actual physical layout of
> the drive.
>
> However I am also aware that CHS is _standardized_ and, exactly as you noted,
> is still required for some antiquated operating systems.  As it turns out,
> it is *also* required for *current* version of FreeBSD, if and only if one
> is electing to use a traditional MBR partition table, rather than a newer
> style GPT partition table.  I have discussed this point with other FreeBSD
> users and it has been reported that GPT is still by no means universally
> understood by motherboard BIOSes, and thus, I am one of the people that
> elects to continue to use... or at any rate tries to use... MBR partition
> tables.  Unfortunately, FreeBSD believes that MBR and CHS addressing are
> inseparable, and that use of the former mandates use of the latter.  Thus,
> by electing to continue to use MBR partition tables (for the sake of
> hardware compatability with the great mass of older hardware I have here)
> I am being effectively forced, by FreeBSD, to also use a cylinder-based
> partitioning.
>
> Given the above facts, it is not really helpful for me to receive a lecture
> describing the antiquated nature of CHS addressing.  As I say, I was and
> am already well and truly aware of that, and in my specific situation,
> my personal preference for LBA is utterly irrelevant.  Gparted can make
> the choice to be flexible enough to help, in my unusual circumstance,
> or else it can make the choice to be utterly unhelpful.  Right now it is
> making the choice to NOT be flexible enough to help, which I feel is a pity,
> and also a pointless and unnecessary limitation of an otherwise very flexible
> tool.
>
> But really, all of the foregoing is utterly unimportant and irrelevant.
>
> The most important point is the one that was contained in my original
> bug report, i.e. that if Gparted is going to allow... AS IT DOES... a
> setting to request alignment of a new partition to cylinder boundaries,
> then it is nonsensical, unhelpful, and in fact downright absurd if,
> when that option is selected, Gparted does not follow suit and also
> allow the *size* of the partition (and the space preceding) to be
> specified in cylinders as well.
>
> What Gparted should not do is to make a half-hearted pretense at supporting
> partitioning by cylinders if it is not going to actually implement that
> ALL THE WAY.  I think that Gparted should either support partitioning by
> cylinders or not.  This half-way stuff is just entirely unhelpful.  For
> example, I was deluded... but the current Gparted GUI... into believing
> that I could in fact use Gparted to partition, based on cylinders, but
> in reality the current (GUI) implementation of that is so hobbled and
> messed up that it is effectively unusable and unworkable.
>
> For all of the foregoing reasons, I disagree with your reasoning entirely,
> and I request that you re-open the bug report.  Either Gparted, and its
> GUI, should implemennt *full* support for partitioning based on cylinders,
> or else it should drop the silly pretense that it actually supports such
> partitioning, when in fact it doesn't... not really.


Currently the only unit available for specifying the size in the GParted GUI is by MiB.  A request for permitting other specifying other unit sizes already exists.  See:

Bug #622150 - Support for data entry and display of logical blocks (sectors)


Note that the alignment control will convert from the specified MiB units into appropriate values for the partition boundaries.

For example if I create a 40 GiB partition at the start of my 160 GiB hard drive (512 bytes/sector) using cylinder alignment, then the partition boundaries after creation are:

Start Sector:          63
  End Sector:  83,891,429

These values are cylinder aligned and result in a 39.2 MiB partition (83,891,367 total sectors).


Hence GParted does support cylinder alignment, but does not support specifying units other than MiB in the GUI.

If your request is to have units other than MiB in the GUI, then perhaps we should add the cylinder unit to bug #622150, and mark this report as a duplicate of bug #622150.

Thank you for your response.

>Note that the alignment control will convert from the specified MiB units into
>appropriate values for the partition boundaries.

One question:  Where do it say that?  I mean in the GUI?

It is all well and good for you to explain this fine point to me here, and now, but what about the poor schmuck who naively just comes along and tries to use the GUI-wrapped version of parted, perhaps for the first time ever.

What you have described (and clearly, I think) is rather entirely counter-intutive from the user's perspective.  What you have said is that if the user asks for `N' MiBs, but has alignment set to cylinders, then what he will actually get is something that is somewhat different from exactly `N' MiBs.

I do not like user interfaces that play fast and loose with the truth.  They are distinctly user-hostile.

The problem could be rectified if the GUI simply _showed_ the user the amount of cylinders and sectors that will _actually_ be allocated, given the current/pending request for a partition of size `N' MiBs.  Surely this would not be a hard thing to add.

Just as the free-space-following field seems to change automagically as I change, e.g. the start and/or size of my pending new partition request, so too a set of little boxes next to the start, size, and following fields in the GUI new partition dialog could show numbers of cylinders and numbers of sectors, for each of the user-selectable start/size/following values and the values shown in these new little boxes also could be dynamically updated by the GUI as the user changes the corresponding data entry field values... which are denominated only in MiBs.

Surely none of this can be difficult, especially given (as you say) that Gparted necessarily is going to do the calculations anyway, before actually creating the new partition.

Right now, the GUI is playing a counterproductive game of "hide the ball", i.e. declining to tell the user where, exactly, and what size, exactly, the partition he is about to create will be.  This bug report should be reopened, and that bug should be fixed.  Showing the user only the approximate truth is not nearly as user-friendly as having the common courtesy to show the user the _actual_ and precise truth.


P.S.  This bug is quite definitely _not_ the same as bug #622150.  That bug asks for an enhancement to allow the user to _enter_ arbitrary LBA block numbers.  That would be Nice, yes, but here, and for the time being (until someone decides to implement THAT new feature request) I am only concerned with the user's ability to _see_ the truth.. _not_ to enter it...

... and the truth will set you free.

Hi Ron,

Please accept my apology for quickly dismissing this bug report before you had a chance for further explanation.

In an effort to understand your position I will take a different tact and proceed by asking one question at a time.

What other partition tools or Operating System install wizards have you used that prompt for partition size in units of cylinders?

Objection yer honor.  Question is irrelevant and immaterial.

Just because other tools screw this up (and are equally user-unfriendly) that is no excuse for Gparted to be likewise user-hostile.

I was hoping that this tool would be _better_ than others.

Anyway, to answer your question, the *current* FreeBSD install process allows for specification of -size- but not -alignment-.  With respect to -size- there is no specific prompt for the units used to specify the size of a new partition.  The user is simply asked to enter a number, and that number _may_, at the user's option, be suffixed with either an "M" or a "G", to indicate MiBs or GiBs, respectively.  (I do not believe that "" is supported yet, or at the present time, but I could be wrong about that.)  In the absence of any such suffix, it is my understanding that the number entered for partition size will be interpreted as a number of 512-byte -sectors-.

I only add all this information so that you will understand that I am not attempting to be impolitely evasive.  However I stand by my earlier comment above, i.e. that regardless of the (lousey) limitations of the FreeBSD install-time partitioning capabilities, I really was hoping that Gparted would be a better tool than that.

I wrote:

I do not believe that "" is supported yet, or at the
present time, but I could be wrong about that.)

Sorry. Typo.  There should have been the letter "T" within the double quotes.

Do you think there might be a reason why other partition tools and Operating System install wizards (both proprietary and open source) use units such as MB, and MiB, and not cylinders?

I cannot answer _in general_ for all "other partitioning tools" (can you?) nor even for what a substantial fraction of such tools might or might not be doing at the present time.  I have have direct personal experience with four such tools... the FreeBSD one (which has recently been dramatically revised/replaced), Windows {200,XP,7}, ArchLinux, and Gparted.

However if forced at gunpoint to guess why the small subset of other partitioning tools that I have worked with seem to want size/alignment specifications given in either sectors or MiBs or GiBs, I would be forced to guess that it is due to a combination of two factors, i.e. (1) the fact that MBR is being replaced by GPT (and the latter is... unlike MBR... not defined with respect to "cylinders") and also (2) laziness.

There are two key problems I foresee with cylinders, and are likely reasons I think other partition tools do not use cylinders.

a)  The size of a cylinder varies because it is a calculation as follows:

    Cylinder Size = (Number of Heads) * (Sectors per Track) *
                       (Bytes per Sector)

    Hence a cylinder is not a guaranteed consistent size

b)  The computer world uses bytes and multiples of bytes, such as kB, MB,
    kiB, MiB, etc to measure size.  As such these are the units that are
    familiar to computer users.

Even back in the days of DOS, the partition tools did not use cylinders to specify the size of a partition when aligning a partition to cylinder boundaries.

Closing this report as there are no plans to change the way GParted handles disk cylinders.