# [parted-devel] [PATCH] Properly sync partitions with operating system

Tue Feb 24 17:15:55 UTC 2009

```On Tue, Feb 24, 2009 at 04:58:55PM +0100, Jim Meyering wrote:
> ...
> >> Between now and when parted learns to support
> >> some _new_ partition table type that works that way,
> >> we should have plenty of time...
> >
> > Sorry for taking so long to respond but I had to be sure.  Been reading
> > the EFI GPT specification
>
> Thanks for doing the research.
> However, could it be that there is an effective maximum
> that is a constant?
>
> Consider the width in bits of the field defining
> FirstUsableLBA.  That gives a maximum possible value.
> Plug that into the equation for SP, and you have a maximum

Not exactly.  Because the size of the Entry Array element is also dynamic.
Moreover the block size is dynamic.
I guess that if we wanted to calculate a static number we would have to
consider the smallest sizeof(entry array element) and a block size of
512.  In which chase the equation would be:

SP = offsetFirstUsableLBA - 2offsetLBA3 / min(size(EntryArrayElement))
SP = ((8 byte maximum)*(block minimum)) - 2(block minimum)/ min(sizeof(Entry Array element))
SP = ((9223372036854775808*512) - (2*512)) / 128
SP = 36893488147419103224

Now, the previous equations is trying to be very precise.  I know in
real life the user will not have something near 36893488147419103224
partitions.  But this would be the theoretical maximum that gpt could
support.

I could calculated with the values that parted uses but that would
ignore the fact that other apps also create gpt partitions.

In other words we have three choices:
1.  call ioctl 36893488147419103224 times to make sure that we cover *all*
the partitions
2.  we read the partition header and calculate just how many partitions
this table can hold.
3.  We randomly guess a number and work with that.

I prefer 2, adding Jim's suggestion of modifying the way the functions
return an error.  I can live with 3,  guess we just need to arbitrarily
decide on the value.  1 just sounds outrageous.

Again, If anyone sees any mistakes in my math, pls let me know.

Jim:
Whats wrong with reading the device?

regards.

>
> If there really is a hard requirement to read from disk or to do anything
> else that may fail, one way around the poor-interface problem is to use
> a different signature for the function: return a boolean to indicate
> success or failure and set the result (only upon success) through a
> pointer parameter.
>
> > (http://developer.apple.com/technotes/tn2006/tn2166.html Chapter 5)  As
> > I understand it, gpt *is* a type of label that needs a read to find out
> > the maximum number of partitions that it can hold.
> >
> > According to the specs the first LBA (LBA0) is not relevant (it exists
> > to maintain compatibility).  on the second LBA(LBA1) gpt places the
> > find the Entry array.  Each element of said array, describes each
> > partition.  One can have as much elements as can fit between the end of
> > the second LBA (where the header ends) and the FirstUsableLBA.
> > FirstUsableLBA is the first logical block that may be used for contents
> > and is defined in header.
> >
> > /---------------------------------------------------\
> > |        |        |             |                   |
> > | BLOCK0 | HEADER | Entry Array | First Usable LBA  |
> > |        | BLOCK1 |             |                   |
> > \---------------------------------------------------/
> >                  /              \
> >     /----------/                  \----------\
> >     /-----------------------------------------\
> >     |      |      |                           |
> >     |  E1  |  E2  |  E3  ................  EN |
> >     |      |      |                           |
> >     \-----------------------------------------/
> >
> > So.  The number of possible partitions or supported partitions (SP) is:
> > SP = (FirstUsableLBA - LBA3) / sizeof(Entry Array element)
> > Note that FirstUsableLBA and sizeof(Entry Array element) are values that
> > can change.
> >
> > And to take calculate said value, we have to read from disk.
> >
> > Now, the spec file for gpt is rather easily acquired.  I don't know
> > about the other.  I would appreciate people sending me specs for the
> > other types of labels in which I can verify the way to calculate the
> > maximum number of supported partitions.

--
Brno, Czech Republic, Red Hat.

```