On Tue, Jul 05, 2011 at 12:28:38AM -0430, Andres Perera wrote:
> On Mon, Jul 4, 2011 at 11:32 PM, Kenneth R Westerback
> <kwesterb...@rogers.com> wrote:
> > On Mon, Jul 04, 2011 at 09:38:37PM -0430, Andres Perera wrote:
> >> On Mon, Jul 4, 2011 at 8:56 PM, Kenneth R Westerback
> >> <kwesterb...@rogers.com> wrote:
> >> > The use of CHS should be hard and attempted only by
> >> > those who know all the rules already.
> >>
> >> which is made difficult by not being able to select a subset of cyls,
> >> since fdisk caps them at 1024 on amd64
> >>
> >> note that geom was, and continues to be, only relevant for the
> >> duration of that fdisk instance
> >>
> >> all the changes are just to help with partitioning, e.g. by using a
> >> percentage based on the subset of cyls that i could select, or just
> >> globbing the entire cyl range
> >>
> >> at the moment it is not for people that know the intricacies, as
> >> you're implying. it doesn't allow for anything useful
> >>
> >> if geom is removed from fdisk, then the obsd install ideally has to
> >> account for geom changes before making mbr partitions
> >
> > MBR partitions are created based solely on lba info, with the chs
> > info just faked in. Removing geom would have no impact on the install
> > as far as I know. At least for 99.9% of situations. That would be
> > an interesting experiment.
> >
> > .... Ken
>
> even though it's ultimately the same for people that don't change
> them, mbr partitions are not created from lba in fdisk.
>
> the data goes through this mangling:
>
> 1. lba (disklabel, which means that it's not necessarily lba)
> 2. boundless CHS
> 3. boundless CHS is influenced by geom ("disk" command)
> 4. 255/63 check (cylinders are ignored for the check and always written as
> 1024)
> 5. partitions are created based on boundless CHS, partition end is
> usually aligned with last cylinder
> 6. dishonest bounded CHS gets written to mbr
>
> from this point, it either writes 255 in all CHS fields except the 2
> bit S field, or an almost honest representation of lba
>
Or, as I said, CHS values are largely fictitious and the overriding
information is the LBA information.
> since you can change the "boundless CHS" through geom, then CHS values
> do influence, just not the ones in the MBR... it's important to make
> that distinction in order to get anywhere with this mess
You can influence the CHS, since user information overrides other
information, It is this that is dangerous and to be discouraged.
>
> besides that,
>
> for people that want to partition mbr after *really* changing CHS
> values: during install they have to access the shell and change CHS
> with disklabel before fdisk. that's fine since it is an unusual need:
>
> disklabel (fill in boundstart and end, or don't partition yet) ->
> fdisk -> disklabel
>
> but two things need to be clarified: the order is assbackwards.
> disklabel influences fdisk, and fdisk influences disklabel (to set
> boundstart and boundend). this complexity is a problem no matter what
> happens to geom with fdisk
>
> the second thing is that the "disk" command is misleading since it
> does not expose the relationship between disklabel and fdisk, in fact,
> it actively confuses how the two relate. improving the "disk" command,
> like i suggested + writing to disklabel, would lead to less circling
> dependencies. but the better solution requires more drastic changes
> than the ones i proposed: disklabel should not handle geom +
> partitions, it's a mess. whatever handles geom comes before fdisk and
> disklabel
Changing the disklabel will (or should not) have any effect on the information
being used by fdisk. fdisk uses DIOCGPDINFO to obtain a 'spoofed' disklabel
that contains no information you may have written to disk. The
'spoofed' disklabel is generated by the kernel, almost always based only on
the size of the disk and the size of the disk sectors, all the other information
being faked by either the device itself or the kernel if the device doesn't
make sense. While fdisk will fall back to DIOCGDINFO when DIOCGPDINFO is not
available, in practice all disk types now support DIOCGPDINFO.
In fact it is the MBR that can influence this 'spoofed' disklabel, since
the bounds of the OpenBSD area of the disk are set from the first OpenBSD
MBR partition found. See readdoslabel() in /usr/src/sys/kern/subr_disk.c.
If you can successfully influence fdisk's idea of the disk geometry by
changing the on-disk disklabel I would be very interested in hearing
exactly how you did it on a -current system.
.... Ken
