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: Wed, 07 Mar 2007 15:44:50 +0200

Simon 'corecode' Schubert wrote:
[your email address is broken]

that's intentional, as the spam is out of hand.
However, I check here frequently. If anyone would like to mail me, please say so in the thread and I'll get back to you.


On 06.03.2007, at 15:48, randux@noreply.org wrote:
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 doubt any fdisk does rounding to get nice human numbers.

Yet, it happens. It has to happen, because the manufacturers don't build disks with integral 1024 units.



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.

So you're actually destroying the slice and then re-creating it? This is important information. Until now I was under the impression that the installer changes the slice table without being asked to change slices.

No, where did you get the impression I'm destroying a slice and then recreating it? The issue is the two things I stated (which weren't included in the reply).


Here's what I wrote earlier:

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


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.

So the slice table shouldn't be changed at all, I guess.

That's right.



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.

Actually the OS do not use any CHS view. It is *only* fdisk we're talking here about. After having set up the slice table, nobody cares about CHS.

Agreed, I don't mean to split hairs, to me fdisk is part of the OS.
Nobody cares but fdisk *and* disklabel. Disklabel also thinks in sectors and cyls. Have a look and see.



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.

fdisk can already do this, so this is "simply" a matter of adding this to the installer. However, I disagree that this feature should be exposed to common users. Setting up CHS values is a rather advanced topic, so I simply suggest doing a manual install instead, where you have everything under control. A clean user interface is an important thing. Maybe it could be integrated into expert mode, however.


Yet, I suggest not to care about CHS at all. Simply ONLY care about LBA. Don't care to put slices on cylinder boundaries. Where is the point in this anyways?

The point is what I said: cylinder size is important because DFly changes the partition table to match his view of what an integral cylinder boundary means. If he doesn't change the partition table, and doesn't exceed the slice allocated to him, then we can reach the level of "not to care about CHS at all." Until then, it's a significant data integrity exposure.



I don't understand why he doesn't simply use the unit values in the partition table.

Yah. It shouldn't even re-create the slice.

Right.


Not only should it not even recreate the slice, it shouldn't touch the partition table unless I ask him to in fdisk.



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