Re: workaround for BIOS / CHS stuff

[Andrew Clausen]

On Sun, Jun 27, 2004 at 12:56:33PM +0200, Szakacsits Szabolcs wrote:
> > Ah, good point.  I didn't think about linux ntfs tools.
> 
> And probably about other imaging (dd, partimage, mondo, etc), recovery,
> etc, etc. tools. When they either just blindly copy old data or use the
> broken kernel ioctl then the values can be incorrect.

If you backup/restore, then the values should be the same.  Disk
imaging might be a problem though.

> > > AFAIK you use HDIO_GETGEO to get the BIOS geometry, right?
> > 
> > At this stage, yes.
> 
> So you basically get some random values (on all kernels) then making
> decisions, asking questions from users based on that. Non-sense.

The CVS version quietly adopts the file system geometry.

> > Each partition has its start and end values stored twice.  Once in LBA
> > form, and once in CHS form.  Parted always keep the LBA the same
> > (unless you resize).  It will update the CHS form to be consistent
> > with its view of the BIOS's CHS geometry.
> 
> When I tried to resize an NTFS by parted it didn't allow me. At least
> QTParted and SUSE's YAST can do it and sometimes parted shifts the
> partition start (when it got the geometry wrong thus adjusted it to
> cylinder boundary). Of cource this breaks the filesystem, because the
> start position mustn't be changed during repartitioning the partition.
> 
> SUSE uses just parted, QTParted uses libparted for the partition table
> manipulation.

Why didn't anyone tell me about this before? :(

I just had a look at the QtParted source, and it doesn't set a constraint.
It should set a constraint telling libparted not to move the start.

Vanni: perhaps you should add a function set_geometry_exact() or
something, and use ped_constraint_exact()?  (Or
set_geometry_start_fixed(), etc.)

> You say, they are broken.
> 
> They say, parted is broken.

Do they?

> What's the truth then? 

Until recently, YAST has been non-free software, so I can't comment on SuSE
yet.

> Yes, used to. But because it wasn't reliable (see the destroyed partition
> tables by parted running on 2.4 kernels), kernel even stopped guessing. 

Which one are you referring to here?

> > > They report the disk geometry and usually this is not what parted expects.
> > 
> > You mean "usually wrong".
> 
> Yes. Most often the number of logical heads are 240 or 255. But 2.6
> kernels report often 16 in the problematic cases. Parted rewrites the
> partition table with incorrect CHS, adjust to the wrong, imaginary
> cylinder boundary thus the partition is gone,

?

> or in a better case it's only unbootable.

(you can always switch the BIOS to lba)

> One of the explanations why parted damages partition tables on 2.4
> kernels,
> 
>    http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/4682.html

Parted isn't mentioned, but I take your point about even 2.4 being
imperfect.

> One example with recovery when parted damaged a partition table on 2.4
> kernel,
> 
>    http://qtparted.sourceforge.net/forums/viewtopic.php?t=144

This looks like the above bug in qtparted.

> > I'm uncomfortable with the concept of an inconsistent partition table.
> 
> So 
>     1) you're uncomfortable with the concept of an inconsistent partition
>        table.
> 
>     2) kernel can't get the needed logical CHS in a reliable way to fill
>        the needed entries in the partition table
> 
> still parted rewrites the CHS in the partition table based on info from an
> unreliable source and being uncomfortable what it means.
> 
> Does fdisk do this? No.
> 
> Do Microsoft's fixmbr, fixboot, Windows reinstall do this? No.

OK, here's a reason why I'm uncomfortable:

(1) Whenever we want to either move the start of a partition, or install
a bootloader, or create a new windows partition, we need to get the
CHS geometry right.

(2) If partition tables are our primary source of information about CHS
information, then they are the primary data needed to do (1).

(3) If we systematically create partition tables that are inconsistent,
then the data is "tainted".  One mistake can snowball.

So, the passive solution means we wouldn't have a "pure" CHS data source,
only conflicting evidence.  The passive solution also gives no advice
for creating new partitions, boot loaders, or resizing the start of
partitions.

There is a third option: demand all users use LBA, and get good at
picking up the absense of LBA.  Is this doable?

Cheers,
Andrew