2015-10-07 1:38 GMT+08:00 Ted Unangst <t...@tedunangst.com>: > Mikael wrote: > > 2015-10-07 0:58 GMT+08:00 Ted Unangst <t...@tedunangst.com>: > > > > > > the disklabel is the second sector of the openbsd part of the disk. > > > > > > *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] > OpenBSD > > > > > > so, if you overwrite sector 65, you will overwrite disklabel. normally > the > > > 'a' > > > partition overlaps the disklabel, but you made 'e' first. > > > > > > > Ugh, ok - just to settle this one forever I hope, four brief Q:s: > > > > 1) Does this mean that on an ordinary disk (where the "a" partition is > the > > disk's first partition, and starts at the offset autogenerated as default > > option by the "disklabel" tool), the start of the "a" partition" actually > > overlaps with disklabel-internal data? > > Yes. So, the metadata on a x86 disk will look like: > > |start ---------------------------------------------- end| > |MBR . somestuff | OpenBSD partition --------------------| > | .............. | disklabel ----------------------------| > | .............. | FFS 'a' ---- | swap 'b' --- | FFS 'd' | > > FFS knows it should not use the first few sectors of a partiton, because > other > things may live there. > > This may not be obvious to start, but if you think about it, these data > structures have to live *somewhere*. If you cannot see reserved space > between > areas of disk, then the reserved space must be somewhere inside those > areas. >
Ah sure. Perhaps I misunderstood the level of "foolproofness" that the disklabel tool's autogenerated default value was intended to give - Just curious, now that structural things like this are at stake (i.e. some user making a seemingly reasonable presumption based on the "UI" should give you partitions where you can really have completely user-defined/custom stuff based on an expectation that the autogenerated values guarantee non-overlapping with other partitions or the disk partition structure itself i.e. the disklabel), what's the motivation for not increasing the disklabel tool's minimum autogenerated offset value from 64 to 80? The tradeoff would be that the world would lose 8KB per disk, and win the absence of needing to debug a complete disk crash, that I just underwent.
