Installer: no option to set geometry/corrupts partition table
randux at noreply.org
randux at noreply.org
Tue Mar 6 06:48:25 PST 2007
Simon 'corecode' Schubert wrote:
On 05.03.2007, at 04:04, randux at noreply.org wrote:
It's tangential that modern machines 'don't use' c/h/s; the issue is
that the partition table is designed around c/h/s values and that's
how space gets allocated. When you use fdisk you can certainly
allocate things in terms of tracks or cyls or megs or what have you,
but the partition table contains c/h/s values and the map is built
around this geometry. There's no other common point of control for
multiple OS coexistence; how else can partition boundaries be respected?
There is simply *no way* to address more than 8 GB with CHS. After that
you're simply out of bits. You have two options after that: either
fill all bits with ones to mark that you reached this limit, or you
simply don't care about the additional bits and wrap around the values.
What is the result of this? You *have* to use logical block
addressing. And really, once you're there, you can't care less about
CHS values and alignment anymore.
Thanks for your note.
I'm not suggesting that anyone is using c/h/s for purposes of
addressing. I'm saying that it's used in terms of allocating space.
Whether the fields are big enough internally to contain cylinders of
sufficient number to map the drive or not is not critical; what is
critical is that the fdisk interface and all the installers work on
allocating space based on their view of cylinder size. The problem is
that if everyone doesn't agree on the size of this thing called a
"cylinder" then the start and end points of the DOS partitions (BSD
slices) will not be equal in everyone's view and encroachment on
neighboring filesystems is inevitable.
Let's consider an example scenario where we use the common Linux fdisk
value of a cylinder arbitrarily valued at 8,225,280 bytes. Further,
we'll agree that there are 255 heads (tracks per cylinder) which would
then necessarily be understood to be 32,256 bytes in size. Lastly, we'll
say that our disk is divided further into a unit called a sector, that
we'll decide that there are 63 such sectors per track, which would then
work out to a nice round value of 512 bytes in size.
We'll work on a fictitious 120GB drive, which is really not 120GB but
rather 120x10**9 bytes in size. I note that Linux fdisk seems to fiddle
with the actual size a bit to get round numbers. (During the process of
working this example out I see that BSD does similarly but not
identically. The main thing to be aware of is that some rounding occurs
for convenience, and will affect the actual space available in the last
cylinder as it will not really be x bytes in size.)
I'll allocate three DOS partitions for my BSD systems using the view of
a cylinder containing 8225280 bytes, and I'll be careful to allocate
things in even units of cylinders.
I install OpenBSD in partition #1 and FreeBSD (using the G option) in
I've been wanting to install DragonFly since 1.6.0 so here's my chance
with the newly-announced 1.8.0_release! I'll install him in partition #2.
I run the DragonFly installer and I receive a message that he is using
values of 232,581 cylinders, 16 heads (16 tracks per cylinder) and 63
sectors per track. He also establishes normative values for sector and
track size which means cylinder size is a derived value. We work
backwards to find the cylinder size from the known dimensions of sectors
per track (63), and tracks per cylinder (16). With this view of the
geometry, the unit values work out as follows:
cylinder: based on a geometry of 16 tracks per cylinder and 32,256 bytes
per track. It works out to be 516,096 bytes per cylinder. Cross
checking, 516,096 x 232581 is more or less 120GB. Everything is fine.
What's the problem then?
The partition table was set up with a cylinder size of 8,225,280 bytes.
DragonFly uses a different view of cylinder size as 516,096 bytes.
These cylinder values are not integrally related, that is, 516,096 does
not divide 8,225,280 evenly.
When DragonFly calculates the partion cylinder ranges based on his view
of the geometry, he will almost certainly never find that the LBA value
which should be the end of an integral cylinder boundary is the one that
the partition table says is the end of his slice. Therefore, he
automagically (and I'll say improperly) adjusts the LBA up or down (this
part can only speculate- he makes an adjustment according to the message
posted but it could be that he only increases or decreases, I don't know
what he does) to be on an integral boundary from his view of the
cylinder size. What is certain is that he does adjust the partition
range to correspond with his view of a cylinder containing 516,096
bytes. I'll guess that he rounds up, which is quite a bit worse; if he
rounded down it would be wasteful and unnecessary but wouldn't expose
the data on the mext partition to loss/corruption.
Depending on how he rounds, and what the preexisting view of cylinder
size in the DOS partition table is, you can readily see that his view of
his slice may well encroach on another partition.
I should have given a better explanation at the start, I apologize for
anything that was unclear. The main idea here is that regardless of how
data is being addressed, it's being allocated by every OS in terms of
his view of how big a cylinder is. And if all OS on the drive don't
share the same view, and therefore agree on the start/end addresses of
partitions, there can certainly be loss of data.
This is why it seems to be essential to provide a way to change
DragonFly's view of the disk geometry as necessary to match the geometry
the partition table is already using.
However, I do agress that changing existing table values is a really bad
thing, so the installer shouldn't do this in any case.
Yes, it would be sufficient, if we're not able to easily provide a way
to specify geometry. At any rate, we agree that he should not touch the
partition table. After all, we've already gone through fdisk and
disklabel by this point. If anyone wanted to change things he could have
done so at the proper time.
I should point out that the installer did two bad things:
1. adjusted the geometry settings in the partition table (from c/h/s of
14593/255/63 and to a c/h/s of 232581/16/63)
2. changed the ending point of the DFly slice (DOS partition) to match
the DFly view of what it means to be on an integral cylinder boundary
It's certainly improper to modify the partition table units and it's an
imminent risk for the data on the drive in a multiboot scenario to
change partition boundaries.
I don't understand why he doesn't simply use the unit values in the
All the other BSDs installers make provisions for preventing
this...that being the case, I don't understand the skepticism or the
surprise! It hardly seems reasonable that all these other variants
make a provision to deal with an issue that is obsolete or irrelevant.
Rather, it seems extremely critical. If I understand correctly that
the DFly installer was taken from the FreeBSD installer, then I am
hoping it will be a very simple matter to add the G option to DFly's
No, you are mistaken. The DragonFly installer is really the
BSDinstaller, but a rather oldish version. Possibly you mistake the
source of scepticism. We're just too few people to do everything people
could possibly need. If you want to fix this issue, please go ahead!
We appreciate every helping hand!
I stand corrected, thanks for the clarification.
I'm sorry if it seemed as though I were saying "I know how to fix this,
why don't you take care of it?" Really I meant to say, I know what the
problem is, and I don't know how to fix it or even more importantly, how
to circumvent it. The few responses I got seemed to range from "yawn" to
"no, it's not happening as you think" which certainly didn't sound like
what you just said! I would be delighted to help but alas, I'm not
expert in any of the areas one would need to be knowledgeable in to do
anything about this other than to recognize the problem and ask for help.
I was hoping when I posted the question in the user list that someone
would say "yeah, you simply do such and such a thing in fdisk and this
problem won't happen" but since I didn't get such a reply, I decided to
More information about the Bugs