From mlord@pobox.com Mon Aug 24 17:37:12 1998
We debated this update a few months ago on the kernel list,
and there were no objections then, from you or anyone else.
Not surprising (in my case). I stopped reading linux-kernel
at the moment the news interface was killed. The mail interface
is too inconvenient for someone who only spends a very small fraction
of his time on Linux development.
(Still, I am not entirely out of touch. Often people cc me,
or just tell me that something interesting is happening on linux-kernel,
and quote an article. In cases where I have too much time on my hands I
sometimes use some guest account that gets linux-kernel. But don't
count on me seeing something: even when using this guest account
I start throwing out 2000 of the 2300 messages waiting, and only
look at recent stuff. Often half of that is some flame; the
information density of linux-kernel via mail is very low.
A news interface is more efficient.)
The intent was to respect any existing geometry found in the partition
table, and default to LBA translation for drives which did not already have at
least one valid entry in the table.
The motivation is simple: I get tons of emails complaining that
whenever a new disk is installed, Linux defaults to the "wrong"
translation.
But.. the patch is still incorrect, I suppose.
Andries: we really could use some of your non-flaming expertise here..
how about fixing that for-loop in genhd.c to skip the new LBA
translation if any valid partitions are found on the drive.
Fix it for us. Thanks.
Ah, what a dirty trick to ask the question like this.
I sat down immediately to type the code, but realized that a new disk
without partitions either has random data, or has all zeroes everywhere,
and certainly does not have the msdos magic constant in its last bytes.
So, the for-loop you mention is never reached if the disk is empty -
the routine msdos_partition() is left at
if (*(0x1fe + data) != MSDOS_LABEL_MAGIC)
return 0;
Thus, genhd is the wrong place to look for a new disk.
On the other hand, I do not know all possible disk labeling systems,
and could imagine that some disk labels leave the first sector(s)
alone, perhaps for bootstrap code, so a blank first sector is not
a good criterion either.
This is the detection side. We can solve that, if we think about it.
But then, what to do? Maybe you saw my somewhat detailed answer
to some fuzzy posting. Assuming that it is correct what I stated,
then the BIOS may decide to use 240 heads, it may also decide to
use 255 heads, it may also decide not to use any translation at all -
Win95 OSR2 and Win98 have learnt how to deal with disks over 8 GB
and do not need a translation anymore, since translation cannot help us
past 8 GB anyway. So we cannot know whether, even assuming the disk will
be used by several operating systems, among which windows, any translation
will be used, and if so, which.
Conclusion: it is not the kernel's job to guess here what is right.
This is user space stuff. If someone wants to use Windows 2000 she'll
have to use the FDISK from that. And Linux will adapt to whatever it finds.
If the user starts with Linux fdisk she may get something that doesnt work
well with DOS. If we can identify particular classes of such cases, we
might change defaults in *fdisk, or warn the user.
Best wishes - Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html