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

[Joel Granados]

On Fri, Feb 20, 2009 at 01:27:24PM +0100, Jim Meyering wrote:
> Joel Granados <jgranado at redhat.com> writes:
> > On Fri, Feb 20, 2009 at 12:14:47PM +0100, Jim Meyering wrote:
> >> Joel Granados <jgranado at redhat.com> writes:
> >> ...
> >> >> > If the only values ever returned are non-negative (as it seems they are),
> >> >> > then it'd be far more readable to make the return type "unsigned int".
> >> >> > Otherwise, I have to wonder if some of these functions may return a
> >> >> > negative value, and write code in each caller to handle that.
> >> >> >
> >> >>
> >> >> Seems like a good idea.  And: No, they are supposed to be possitive
> >> >> values.  Note this will propagate into other elements of the patch as
> >> >> well.
> >> >
> >> > On the other hand, ped_disk_get_max_partition would need to return -1
> >>
> >> Yes, but that's a different function.
> >> From what I recall reading, your new
> >
> > mmm. sorry got confused.
> >
> >>
> >> >> > > +extern int ped_disk_get_max_partition_num(const PedDisk* disk);
> >>
> >> merely queries the code for the appropriate partition table type
> >> and always returns a non-negative number.
> >
> > well.  The specific code in each label might return a negative number
> > for error as well.   Think of some spec that defines that maximum number
> > as something that might be read from disk (just playing the devils
> > advocate here).  The read from disk might fail and then it must be able
> > to tell the calling function that something when wrong.
> 
> 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
(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
header.  The header is as big as a logical block.  After the header we
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.

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.