DragonFlyBSD

seems to be a problem with our gpt. I'll take this one.

Cheers,
Alex Hornung

It seems gpt starts numbering slices at 0, so the usual ad4s1 is ad4s0, ...
leading to the fact that the expected ad4s3 is at ad4s2.

In any case, I'll update our GPT code to fix some other issues (for example
the slice type is always set to 1).

For reference:
7:46:26 dragon:~

1. gpt show /dev/ad0
   start size index contents
   0 1 - PMBR
   1 1 - Pri GPT header
   2 32 - Pri GPT table
   34 6 -
   40 409600 0 GPT part - EFI System
   409640 293391 1 GPT part - Apple HFS
   703031 400000 -
   1103031 185671 2 GPT part - MS/Linux Basic Data
   1288702 808417 -
   2097119 32 - Sec GPT table
   2097151 1 - Sec GPT header

7:47:05 dragon:~

1. newfs_msdos /dev/ad0s2
   /dev/ad0s2: 185276 sectors in 46319 FAT16 clusters (2048 bytes/cluster)
   bps=512 spc=4 res=1 nft=2 rde=512 mid=0xf8 spf=181 spt=63 hds=256 hid=1103031
   bsec=185671

Observe carefully that the bsec of the newfs actually matches the number of
sectors of the third partition, with gpt index 2.

Cheers,
Alex Hornung

:It seems gpt starts numbering slices at 0, so the usual ad4s1 is ad4s0, ...=
:=20
:leading to the fact that the expected ad4s3 is at ad4s2.
:
:In any case, I'll update our GPT code to fix some other issues (for example=
:=20
:the slice type is always set to 1).

Yah, I'm responsible for the numbering.  With GPT 's0' is index entry 0
    in the GPT.  I did it that way so the index number in the GPT table
    matched the slice number in the device name because it was really
    confusing when they were 1-off.

I don't know what the best solution is but numbering from 0 has caused
    us other headaches so if you want to change it back to numbering from 1
    it's ok with me.  It will mess up anyone using GPT right now, thougg,
    they will have to fix up their fstab and such.

: 40 409600 0 GPT part - EFI System
: 409640 293391 1 GPT part - Apple HFS
: 703031 400000 - =20
: 1103031 185671 2 GPT part - MS/Linux Basic Data
: 1288702 808417 - =20
: 2097119 32 - Sec GPT table
: 2097151 1 - Sec GPT header

So e.g.             ^ index 0, 1 and 2 corresponds to s0, s1, and s2
     right now.

:# newfs_msdos /dev/ad0s2=20
:/dev/ad0s2: 185276 sectors in 46319 FAT16 clusters (2048 bytes/cluster)
:bps=3D512 spc=3D4 res=3D1 nft=3D2 rde=3D512 mid=3D0xf8 spf=3D181 spt=3D63 h=
:ds=3D256 hid=3D1103031=20
:bsec=3D185671
:
:Observe carefully that the bsec of the newfs actually matches the number of=
:=20
:sectors of the third partition, with gpt index 2.
:
:
:Cheers,
:Alex Hornung

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Ooh, it also occurs to me that we could change the construction of
the device name instead of overloading 's#' to remove the confusion.
So for a native GPT we could call it 's0.<index>' instead of 's<index>'.
Or perhaps we could just call it 'g<index'> instead of 's<index>', so
something like: ad4g0, ad4g1, ad4g2, ad4g3.

Just throwing out ideas.

-Matt

Den 2009-12-08 21:26:32 skrev Matthew Dillon <dillon@apollo.backplane.com>:

Ooh, it also occurs to me that we could change the construction of
the device name instead of overloading 's#' to remove the confusion.
So for a native GPT we could call it 's0.<index>' instead of
's<index>'.
Or perhaps we could just call it 'g<index'> instead of 's<index>', so
something like: ad4g0, ad4g1, ad4g2, ad4g3.

Just throwing out ideas.

-Matt

I really like the 'g<index>' idea.

Max

:> 's<index>'.
:> Or perhaps we could just call it 'g<index'> instead of 's<index>', so
:> something like: ad4g0, ad4g1, ad4g2, ad4g3.
:>
:> Just throwing out ideas.
:>
:> -Matt
:
:I really like the 'g<index>' idea.
:
:Max

Oh, except 'g' could be misinterpreted as a partition id
    (a-p).  So we have: q r s t u v w x y z left.  We use 't'
    for track identifiers on audio CDs.

Maybe we should use 'r' or something like that :-)

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Den 2009-12-09 01:13:51 skrev Matthew Dillon <dillon@apollo.backplane.com>:

Oh, except 'g' could be misinterpreted as a partition id
(a-p). So we have: q r s t u v w x y z left. We use 't'
for track identifiers on audio CDs.

Maybe we should use 'r' or something like that :-)

-Matt
Matthew Dillon
<dillon@backplane.com>

Meh, you are right. 'g' would have been the perfect one though :-)

'r' is fine too, I think. The important thing is that the index differs
from 's' so people notice that there is something special with it.

Max