[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS
Patrick J. LoPresti
Re: [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff)
03 Jul 2004 11:00:02 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Andrew Clausen <address@hidden> writes:
> On Sat, Jul 03, 2004 at 10:15:47AM -0400, Patrick J. LoPresti wrote:
> > Parted is primarily a component of larger systems; namely, the
> > RedHat/Suse/etc. installers. Those larger systems can figure out the
> > correct geometry (using whatever logic/heuristics/knowledge they have)
> > and pass it to the tools which need it, of which Parted is just one.
> Why should they bother? Shouldn't libparted just do it all for
> them? (Shouldn't parted use EDD?)
1) "...of which Parted is just one." Whatever logic you fancy for
determining the geometry, the results need to be available to
several tools. Parted is only one such tool; ergo, the logic
belongs OUTSIDE of it. Parted should expect to be TOLD the
geometry in any situation where it matters.
2) The ideal logic varies depending on the capabilities of your
kernel. The distribution vendor knows the capabilities of its
kernel, and can construct appropriate logic. Putting logic into
Parted to handle every possible kernel is a sloppy design.
I hate "smart" software. Don't be smart; be simple. Default to
whatever you like, but give me a way to TELL Parted the geometry.
> I was under the impression that 2.6 provides a mechanism for setting
> the HDIO_GETGEO thingy... so any program can tell Parted (and
> everything else, for that matter) what they want the geometry to be.
> Perhaps I misunderstood your email:
You understood correctly, but see below...
> It contains this:
> echo "bios_cyl:C bios_head:H bios_sect:S" > /proc/ide/hda/settings
> Isn't the kernel the right place for this kind of communication to
> be happening, anyway?
Not according to the kernel developers. They are threatening to
remove HDIO_GETGEO completely.
> > (Note that this would also provide a way for end users to fix their
> > partition tables if/when they broke. Right now, the stock solution
> > for disks which Parted "broke" is "sfdisk -d | sfdisk -C# -H# -S#".
> > Wouldn't it be nice if people could use Parted instead?)
> They can, right? Just type the above, and then do some dummy thing
> in parted. (Parted doesn't have a "touch" command).
No, because Parted will "helpfully" infer the geometry from the
existing partition table, no matter what HDIO_GETGEO returns!
In short, the /proc/ide/hdX/settings + HDIO_GETGEO solution 1) only
works on blank drives and 2) uses an interface which the kernel
developers consider a crock.
> > IBM Thinkpads use x/240/63. In theory, other BIOSes could use
> > anything.
> Do they break on x/255/63?
Yes, absolutely. This is why I wrote the legacy_* support for the
edd.o module in the first place. Otherwise, I could have used
x/255/63 and been done with it.
Re: [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff), Andrew Clausen, 2004/07/02