fdisk(8) vs gpart(8), and gnop

[Marcel Moolenaar]

On Jun 1, 2014, at 8:00 AM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Sun, 2014-06-01 at 08:36 -0600, Warren Block 
>> 
>> Short form of above: gpart is supposed to hide and handle underlying 
>> GEOM issues, so it needs an override to be able to create these 
>> "non-standard" MBRs with slices aligned to arbitrary values.
> 
> Hmm.  If it takes a special "do what I actually said" flag, that's okay
> I guess.
> 
> My problem with that thread is the implicit assumption that CHS
> alignment is required by *something* but there's no evidence what that
> something is, other than "MBR has always in the past been CHS aligned."

That's not what has been said in the thread. What was said
is that if we don't have anything that needs CHS alignment
then CHS alignment can be removed.

Thus: it's ok to change the behavior, but make sure nothing
breaks.

> I don't have enough knowledge in this area to contradict that
> assumption, I'm just always skeptical of "thus it was spoken in 1982 and
> thus it will always be" as an argument against sensible change.  Looking
> at what's done on other modern OSes seems reasonable, for example.

My limited experience in this area has told me one thing:
interoperability is the only goal that leads to success.

We have made seamingly harmless changes (like marking the
PMBR as active), only to find out that it actually breaks
real systems. A broken gpart does not simply impact a
particular FreeBSD version, it impacts every system and
every FreeBSD release that gets exposed to the disk that
has the invalid partitioning. A good example of the last
is the invalid disks we had with "dangerously dedicated".

In short: DANGER, WILL ROBINSON!

-- 
Marcel Moolenaar
marcel at xcllnt.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140602/26e39646/attachment.sig>