Re: Disklabel question (versus bug)

[walt <wa1ter@xxxxxxxxxxxxx>]

On Mon, 16 Jan 2006, Matthew Dillon wrote:

[...]
>     With -r the disklabel program looks at the disk directly...

Further developments have me completely mystified and I'm suspecting
than only black magic can be responsible ;o)

I've used 'dd' extensively while trying to solve my disklabel puzzle.

I just discovered that DragonFly's 'dd', when reading a disklabel
sector, gives a different result than the 'dd' from FBSD, linux, and
a raw-disk editor I use on Windows:

# dd if=/dev/ad1s11 iseek=1 count=1 | hd
1+0 records in
1+0 records out
00000000  57 45 56 82 00 00 00 00  44 46 00 00 00 00 00 00  |WEV.....DF......|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 02 00 00 3f 00 00 00  |............?...|
00000030  10 00 00 00 b7 28 00 00  f0 03 00 00 cf 50 a0 00  |.....(.......P..|
00000040  00 00 00 00 00 00 00 00  10 0e 01 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  00 00 00 00 57 45 56 82  5d 31 08 00 00 20 00 00  |....WEV.]1... ..|
00000090  00 20 00 00 0e 12 a0 00  00 00 00 00 00 00 00 00  |. ..............|
000000a0  07 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 0e 12 a0 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
512 bytes transferred in 0.008378 secs (61114 bytes/sec)


I direct your attention to bytes 908-911, and b08-b11.  These are
the bytes corresponding to 'p_offset' for partitions 'a' and 'c'
in the disklabel as defined in disklabel.h:

        struct  partition {             /* the partition table */
                u_int32_t p_size;       /* number of sectors in partition */
                u_int32_t p_offset;     /* starting sector */

Now, my problem is that FBSD, linux, and Windows all agree that
those two 'offset' fields are *wrong*, and are not zeros but
c0 73 02 09.  This is the correct value for the absolute number
of sectors from the start of the physical disk to the start of
ad1s11.

I can only conclude that DragonFly's 'dd' is looking at that disk
sector through eyes that know the difference between a disklabel
sector and any other sector.  This seems hard to believe, but I
dunno.

Any thoughts on why DF disagrees with the other three OS's?

Thanks!