> The part I most object to are things like
>
> > + id->lba_capacity_2 = capacity_2 = set_max_ext;
>
> There have been many problems in the past, and it is a bad idea to add
> more of this. We should be eliminating all cases.
What problems? This reflects real change in drive's identify
and I think should be replaced by rereading drive->id from a drive.
In order to be able to troubleshoot problems we need to be able
to reconstruct the information involved.
One part is the disk identity info that existed at boot time.
It was read by the kernel, and stored. It is returned by the
HDIO_GET_IDENTIFY ioctl, as used in e.g. hdparm -i.
There is also the current disk identity info.
It is found by asking the disk now, and is returned by e.g. hdparm -I.
> We have info from BIOS, user, disk etc and conclude
> to a certain geometry.
I can't spot place when we get info from a BIOS.
See arch/i386/boot/setup.S
(I ripped out ide-geometry.c recently, so the use has diminished.)
> Sneakily changing what the disk reported is very ugly. I recall a case
> where a disk bounced between two capacities because the value that this
> computation concluded to was not a fixed point. Also, the user gets an
> incorrect report from HDIO_GET_IDENTITY.
User gets correct report from HDIO_GET_IDENTIFY as drive's identify was
really changed. Moreover HDIO_GET_IDENTIFY needs fixing to actually
reread drive->id from a drive (similarly like /proc identify was fixed).
There are at least two objections.
First: we do not want the new identity, we want the old.
Second: if we ask the disk for identity again, you'll see that
more than this single field was changed.
If the user only wanted to know the current max size then there are
other means, like BLKGETSIZE.
> So, the clean way is to examine what the disk reported, never change it
Even if disk's info changes? I don't think so.
Yes. The disk geometry data that we use is drive->*
What the disk reported to us is drive->id->*.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:37 EST