Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics)

Szakacsits Szabolcs
2004-07-05T18:10:02Z

On Mon, 5 Jul 2004, Bartlomiej Zolnierkiewicz wrote:
> On Monday 05 of July 2004 14:14, Szakacsits Szabolcs wrote:
>
> > - nobody could point out any _technical_ benefit why the new
> > HDIO_GETGEO code is better than the old one (the _way_ Andries wanted to
>
> Andries pointed it many times but you seem to completely ignore it

Hmmm. I'm recovering people's partition tables in my spare time,
voluntarily, free of charge when they got trashed due to Andries' and
Andrew's bugs over the last two years (gpart, testdisk and parted's
rescue mode don't always work),

http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot

I reported them several bugs, hints, reasons, potential reasons, guesses,
user feature request both privately and publicly.

I do know very well Andries' arguments, I've learnt them the hard way.
Actually I responded them several times, even in this thread.

> I also pointed out that IDE driver _doesn't_ need BIOS geometry et all.

Thanks but I thought it was off-topic and think the same now, too. It was
explained several times.

However none of you who responded seems to understand, still, what I want
to say.

You can't fix, for example, parted 1.6.11 and all earlier versions when
one does a 2.4 -> 2.6 kernel upgrade. If a user uses an old enough tool on
the new kernels then it can trash its partition table whatever the OS it
is (not only the geometry but the layout in sectors, too).

Also, sometimes [even very popular] distros ship one or two old tools, no
need for kernel upgrade. Whenever a user use the shipped old tool on 2.6
it can trash the partition table, being during install or later.

You, Bartlomiej Zolnierkiewicz, Andries Brouwer and Steffen Winterfeldt
say don't care about those people. OK, at least now it's documented
and this thread can be pointed out as a reference in the future.

Since there is nothing I could do more if maintainers aren't willing to
fix their more destructive 2.6 kernel code, the case is closed from my
part by this email.

Thanks,
Szaka