OCE and GPT

[Andriy Gapon]

on 22/04/2010 18:21 Lister said the following:
> Hello all,
> 
> I'd like to make a few clarifications first:
> 1. All my systems are AMD64 and either 7.1-REL or 8.0-REL.
> 2. The GPT on the 5TB RAID5  I want to expand is on 7.1.  The latter has
> both gpt and gpart. I didn't know about gpart when I built its RAID.
> Partition 3 is the last, 3.6TB, 87% full, and is the one desperately
> needing expansion.

OK.  I can't really comment on gpart vs gpt in 7.
gpart is what's in head and 8 now and it's evolving.

> 3. The GPT on 4TB RAID is on 8.0.  I just built it a few days ago for a
> project (not my own). Its entire 9 partitions are still empty (just
> newfs'd) and for that reason I can use it temporarily for the experiment.
> 
> Certainly, I'll share the results of the expansion experiment with you.
> It'll just be a day or so before I get there, as it evidently calls for
> a good deal of prep.  Fortunately, I wrote a verbose Bash script to
> automate the process of creating a GPT, so I don't have to read
> everything when I need do it again a few months down the line. It
> handles everything from deletion, destruction, creation, newfs, tunefs,
> /etc/fstab updates, mounting and 'df' summary display. To customize,
> only a few variables need be changed.  If anyone thinks this might come
> in handy someday, please let me know to post it.

You can host on web somewhere and post a link.
This way interested parties could discover it and get the latest version of what
you decide to share.

> Now regarding the hexdump commands, I used them on the 8.0 system for a
> reference visual comparision. First here's the output of gpart on that
> system:
> / :633: gpart show da0
> =>        34  7812415421  da0  GPT  (3.6T)
>          34    41943040    1  freebsd-ufs  (20G)
>    41943074   188743680    2  freebsd-ufs  (90G)
>   230686754    62914560    3  freebsd-ufs  (30G)
>   293601314  4294967296    4  freebsd-ufs  (2.0T)
>  4588568610   838860800    5  freebsd-ufs  (400G)
>  5427429410  1111490560    6  freebsd-ufs  (530G)
>  6538919970   209715200    7  freebsd-ufs  (100G)
>  6748635170   629145600    8  freebsd-ufs  (300G)
>  7377780770   434634685    9  freebsd-ufs  (207G)
> 
> Here are the commands. Note that I used Bash notations here for easy
> immediate recognition. I tested everyone of them before submitting this
> message. They do exactly the same as the ones I originally used which
> included absolute lengths (in decimal) and offsets (in decimal,
> hexadecimal and 'b' for block variations).  I've thoroughly tested all
> combinations and proved them to achieve same result (which is nothingness.)
> 
> # First 34 sectors of /dev/da0
> hd -n $((512*34)) /dev/da0
[hd output snipped]
> ……… edited for brevity
> # 34 sectors after the last partition
>    hd -n $((512*34)) -s $((7377780770+434634685)) /dev/da0
> -> frozen
> # First 1 sector after the last partition
>    hd -n 512 -s $((7377780770+434634685)) /dev/da0
> -> frozen
> # Last 1 sector of last partition
>    hd -n 512 -s $((7377780770+434634685-1)) /dev/da0
> -> frozen
> # First 1 sector of last partition
>    hd -n 512 -s 7377780770 /dev/da0
> -> frozen

Could you please try to use dd piped to hd?
What you report makes me think that hd doesn't seek disk to a specified offset,
but reads and discards data until it reaches the offset.  I may be wrong, of
course, but it is worth trying dd which is known to do the right thing.

> This is interesting: Since 7.1-REL has both gpt and gpart, I did both on
> my 5TB array. Here's the output:
> / :1134: gpt show da0
>       start        size  index  contents
>           0           1         PMBR
>           1           1         Pri GPT header
>           2          32         Pri GPT table
>          34  1677721600      1  GPT part - FreeBSD UFS/UFS2
>  1677721634   419430400      2  GPT part - FreeBSD UFS/UFS2
>  2097152034  7668367293      3  GPT part - FreeBSD UFS/UFS2
>  9765519327          32         Sec GPT table
>  9765519359           1         Sec GPT header
> 
> / :1135: gpart show da0
> =>        34  9765519293  da0  GPT  (4.5T)
>          34  1677721600    1  freebsd-ufs  (800G)
>  1677721634   419430400    2  freebsd-ufs  (200G)
>  2097152034  7668367293    3  freebsd-ufs  (3.6T)
> 
> Obviously the output of gpt is more detailed and does reference the 2ry
> GPT.  It lead me to incidentally learn that the 2ry is one sector
> shorter than 1ry on account of absent PMBR.

That's kind of obvious (for those who are into reading specification) - PMBR is
for software that knows only about MBR and doesn't know about GPT.
And MBR, of course, is in the first sector and there is nothing special about
the last sector in MBR scheme.

> This also leads me suggest to the implementers of gpart to use the
> verbosity of gpt.  Would you concur?

Not sure.
I think that gpt is too verbose here, there is not much value in reporting
internal GPT structure.  Perhaps some educational value, but we already have
Wikipedia :-)

-- 
Andriy Gapon