Re: BSDInstaller snapshot

> +> > +> I think BSDInstaller should change to not create first slice at offset 0.
> +>                                                             ^^^^^
> +> Yet another "bsd slice" / "bsd partition" confusion? :-)
> +> 
> +> > 
> +> > Grrr!!! DEFINITELY! Please, first partition at offset 16.
> +> 
> +> Interesting. Sysinstall makes the first "a" partition on a slice at
> +> offset 0 and FreeBSD works properly. What is this metadata on those
> +> first 16 sectors of a slice and when this metadata is really used?
> 
> What?! You only think it works properly. It doesn't.
> UFS works on such partition, because UFS has a hack to skip first 16
> sectors. Swap works on such partition, because swap code has a hack to
> skip first 16 sectors.

UFS was designed to work properly here.  The label was supposed to be
in the first 16 sectors of the disk, so any file system in traditional
unix that dealt with disks also had to cope with this 16 sector
offset.  However, time has marched on since 1970's and 80's when this
was a reasonable thing to do.

Moving it to sector 16 is just as magic as sector 0.  How do we know
that the boot code is going to be 8k?  why not 16k or 32k or 1024k?
There were fields added to the bsdlabel recently for this (d_bbsize)
and the area skipped to reflect this based on the boot code size for
that platform.

> Try to encrypt partition which starts at offset 16 with geli(8) or
> gbde(8). Try to concatenate or stripe two partitions that start at
> offset 16.
> The former will destroy your metadata (at least it did so, not sure if
> you won't get EPERM now). The latter will return EPERM when you try to
> access data in the middle of your concat device or at the begining of
> you stripped device.
> Many evil things can happen, belive me. Using offset 0 and making
> metadata visible from usable partition is BAD. Period.

It would be better to say that having the partitions overlap the
metadata for the partiutions is bad.  We avoid this already for
slices.  Maybe we should also avoid this for bsd label partitions and
the boot code they describe.  It would be a layering violation for the
geom entities to reach into the label to find out if they need to skip
space.

The disk label is only 148 + 16 * 8 bytes long (276 of the first 512
bytes, which was the reason for boot1 vs boot2, since boot1 could only
use 236 bytes of code to get boot2 into memory).  So we should be
careful with the new installer that it respects what we put on disk
rather than hard coding 16.

Finally, there likely needs to be a 'raid override' for the default
values.  Better to waste an entire stripe than to start a partition in
the middle of a stripe.  I'm not sure how best to accomplish this, but
I'm sure that others in the community who routinely tweak this for
optimal performance can comment.

Warner