Re: Installer: no option to set geometry/corrupts partition table

[randux@xxxxxxxxxxx]

Simon 'corecode' Schubert wrote:
> On 05.03.2007, at 04:04, randux@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.

Hi Simon,

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
partition #3.

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 
partition table.

> > 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 
> > installer.
>
> 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 
post here.

Cheers,
Rand