bug-parted
[Top][All Lists]
Advanced

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

Re: workaround for BIOS / CHS stuff


From: Andrew Clausen
Subject: Re: workaround for BIOS / CHS stuff
Date: Mon, 28 Jun 2004 11:07:13 +1000
User-agent: Mutt/1.5.5.1+cvs20040105i

On Sun, Jun 27, 2004 at 09:17:15PM +0200, K.G. wrote:
> But is fixing broken partition tables the primary purpose of Parted ?

No.

> I mean, if an HD don't boot because of an incorrect geometry in the
> partition table, I don't think this will shock anybody if the HD still
> don't boot after resizing or creating a new partition on it. The contrary
> might even looks like black magic to unaware people. That would be quite
> like maybe "defrag" fixing a registry problem under windows, or a
> strange near undetermist think like that.

More like regedit fixing a registry problem. :p

> On the contrary if Parted try to "fix" a good geometry because it
> thinks there is an error in it, but there isn't, this would clearly be
> a bug.

Point taken.

> So IMHO it would be a good idea to use the "current" geometry guessed using
> the partition table, without even checking its consistency with the maybe
> false BIOS geometry (because of the kernels issues). And if the "guessed"
> by kernel BIOS geometry has so many problem, I think it would be a quite
> good idea to completly stop using it. If you are scared by possible snowball
> effect, there should be a tool (or a Parted option) to try to fix broken
> maybe even using the possibly wrong guessed by kernel BIOS geometry info,
> but anyway trying to do partitioning operations on a broken partition table
> is not a thing that an average user will expect to work.
>
> There is a problem when the geometry can't be guessed by reading the
> partition table, either because there is inconsistencies in the partition
> table itself, or because there is no partition table (or an empty partition
> table, or a partition table with a partition that is to small). In the first
> case I think parted should not even try to do anything without informing the
> user about the current situation before. In the second case Parted could try
> advandced detections, but should ask the user anyway.

But, most of the time, LBA is going to work.  Why do we want to bother
100% of users about a 1% problem that will hopefully disappear?

> I don't know if it's 
> possible right now, but the user should be able to force a geometry to
> (imagine that a different PC recognize an unpartitioned HD with a different
> geometry than the current PC, and that the user wants to partition the HD on
> the current PC but use it on the first one, then letting the user specify the
> geomtry would be the only solution). We should also consider that _maybe_
> asking the geometry to the user will be the only 100 % safe solution in some
> cases.

Users will probably just click "ignore", so I don't think it's any more
100% safe.

BTW, it is possible to have insufficient information even if the
table is non-empty.  Eg: if you have only one partition before cylinder
1024 (i.e. all other partitions are above 1024), and this one partition
ends beyond cylinder 1024.

So, is the following a good solution?

(1) when resizing a partition, attempt to deduce the geometry from
that partition alone.  (i.e. by inspecting its partition table entry,
and inspecting its filesystem geometry).  Also, if the start or end
are staying fixed, then just keep their CHS values the same.

(2) when creating partitions, make a global guess, similar to what
we're doing now.


When creating new partition tables, should we assume that the user is
using LBA?

Cheers,
Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]