Re: gpart, slice starts at 0

On Sun, 17 Feb 2013, Erich Dollansky wrote:

>>> gpart destroy -F da0
>>> diskinfo da0
>>> dd if=/dev/zero of=/dev/da0 bs=512 count=34
>>> dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774
>>
>> Someone here on the lists (I unfortunately forget who) showed a
>> sneaky easier way to do this:
>>
>> gpart destroy -F da0
>> gpart create -s gpt da0
>> gpart destroy -F da0
>>
> This did not make a difference.

It's an easier way to destroy the backup table at the end of the disk, 
whether one was there before or not, without having to calculate the 
location.

>>> gpart show  -p da0
>>> gpart create -s MBR da0
>>> gpart add -t freebsd da0
>>> gpart show  -p da0
>>> gpart show  -p da0s1
>>> gpart set -a active -i 1 da0
>>> #
>>> # The following line always gives an error:
>>> #
>>> # gpart create -s BSD da0s1
>>
>> 'destroy' is not recursive.  It destroys the geom found on the device
>> given, but does not write to any geoms inside those geoms.
>>
> This is obvious. What surprises me is that create does not write a new
> and empty description to the disk.

It does, but not being recursive, it does not destroy the geoms inside 
the one given to the command (da0).  You had:

   da0 (MBR)
    da0s1 (bsdlabel)

After the destroy, it became
   da0 (null)
     da0s1 (bsdlabel)

This can happen with any of the setups where there are geoms inside 
other geoms.

>> The second part of your question, about da0 starting a block zero:
>>
>>> [X220]...Appl/Some Tools (root) > gpart show da0
>>> =>       63  312581745  da0  MBR  (149G)
>>>          63  312581745    1  freebsd  [active]  (149G)
>>>
>>> [X220]...Appl/Some Tools (root) > gpart show da0s1
>>> =>        0  312581745  da0s1  BSD  (149G)
>>>           0  312581745         - free -  (149G)
>>
>> That shows slice one starts at block 63, standard for MBR.  The space
>> inside the slice (da0s1) starts at block 0 *of the slice*.
>
> This is a bit confusing for me but it does not really matter as long as
> the programs get it straight.

This is again because of the geom inside a geom setup.  The actual start 
block is the start of the slice (block 63) plus the start of the FreeBSD 
partition inside the slice (currently 0).  When you create FreeBSD 
partitions inside da0s1, they will have nonzero offsets from the start 
of the slice.  There are examples shown here:
http://forums.freebsd.org/showpost.php?p=206204&postcount=11