DragonFly bugs List (threaded) for 2007-03
DragonFly BSD
DragonFly bugs List (threaded) for 2007-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: randux@xxxxxxxxxxx
Date: Tue, 06 Mar 2007 16:48:25 +0200

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




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]