On Mon, 29 Mar 2004, Anton Altaparmakov wrote:
> I have been experimenting a little with what Windows / Linux 2.4 / Linux
> 2.6 think the geometry of a couple of HDs is and the results are not
> very promising. )-:
>
> Using Linux 2.4, HDIO_GETGEO ioctl, I get the same Heads and Sectors per
> Track as Windows on both HDs I tried it on. This is the good news.
> I.e. at least on those two disks mkntfs as it stands now would create
> Windows bootable partitions.
>
> The bad news is that Linux 2.4, HDIO_GETGEO ioctl returns wrong values
You mean 2.6? That's what I'm saying also for a while. It's a known issue
and people are complaining about it because kernel breaks things (e.g.
they can't boot anymore and think Linux thrashed their systems).
I don't know who is the kernel maintainer today but apparently nobody.
Old maintainer, Andries Brouwer, only repeates that the geometry doesn't
exists even if he was/is proved and pointed out to be wrong many times.
The issue was discussed long, several times on linux-kernel without a
satisfying solution.
Szaka
> for both HDs. (It said Heads were 16 both time when Linux 2.4 said 255
> for one of the HDs and 128 for the other.)
>
> So while mkntfs will work at the moment in a few months/years time it
> will probably never work any more without user specified geometry. )-:
>
> I have unfortunately not found _any_ way to get the values returned by
> Linux 2.4 / Windows on a Linux 2.6 system and I tried looking in
> /proc/ide, using hdparm, and using . )-:
>
> This is very annoying to say the least. )-:
>
> Any ideas?
>
> Of course, this all might have been coincidence and someone else testing
> a different set of two HDs might find the opposite.
>
> What we really want to know is how Windows determines the geometry?
> Anyone know?
>
> Best regards,
>
> Anton
>
On Mon, Mar 29, 2004 at 03:48:01PM +0200, Szakacsits Szabolcs wrote:
> On Mon, 29 Mar 2004, Anton Altaparmakov wrote:
>
> > I have been experimenting a little with what Windows / Linux 2.4 / Linux
> > 2.6 think the geometry of a couple of HDs is and the results are not
> > very promising. )-:
> >
> > Using Linux 2.4, HDIO_GETGEO ioctl, I get the same Heads and Sectors per
> > Track as Windows on both HDs I tried it on. This is the good news.
> > I.e. at least on those two disks mkntfs as it stands now would create
> > Windows bootable partitions.
> >
> > The bad news is that Linux 2.4, HDIO_GETGEO ioctl returns wrong values
>
> You mean 2.6? That's what I'm saying also for a while. It's a known issue
> and people are complaining about it because kernel breaks things (e.g.
> they can't boot anymore and think Linux thrashed their systems).
>
> I don't know who is the kernel maintainer today but apparently nobody.
> Old maintainer, Andries Brouwer, only repeates that the geometry doesn't
> exists even if he was/is proved and pointed out to be wrong many times.
>
> The issue was discussed long, several times on linux-kernel without a
> satisfying solution.
Well, to be more precise, my point of view is that roughly speaking
(I know of some obscure exceptions) "geometry" does not play a role
for Linux. Something entirely different is the use of other operating
systems.
What I also claim is that Linux has no way of knowing what geometry
other operating systems will assign to a disk. Different operating
systems invent different translations.
Moreover, there is the matter of the correspondence of BIOS disk numbers
and Linux disk names. Especially when both IDE and SCSI disks are present,
and when more than two disks are present, it may be impossible to get
this correspondence right. Details depend on the type of BIOS.
So, I claim, until now the kernel attempted to do something, and it often
worked, and it often failed.
However, there is really no good reason why the kernel would try to guess
at the geometry other systems like to see. For the past years, the main
thing the kernel did was inferring the desired geometry from the partition
table. But fdisk or LILO or whatever can do that as well. So, really
no kernel help is needed.
I say this every few months and have not ever seen a good reason why
this code would have to be in the kernel.
(In other words: please, never use HDIO_GETGEO, the kernel does not
have an opinion anymore, and HDIO_GETGEO produces random results.
Do as *fdisk does: get a geometry, if one is needed, from the
partition table.)
(And, you say, what if I am partitioning an empty disk to be used
by DOS/Windows? There my stock answer "look at the partition table"
fails, but there is some EDD stuff that could be used instead.
Of course one should always use the FDISK of some operating system
to create partitions for that operating system.)
Andries
On Mon, 2004-03-29 at 14:48, Szakacsits Szabolcs wrote:
> On Mon, 29 Mar 2004, Anton Altaparmakov wrote:
>
> > I have been experimenting a little with what Windows / Linux 2.4 / Linux
> > 2.6 think the geometry of a couple of HDs is and the results are not
> > very promising. )-:
> >
> > Using Linux 2.4, HDIO_GETGEO ioctl, I get the same Heads and Sectors per
> > Track as Windows on both HDs I tried it on. This is the good news.
> > I.e. at least on those two disks mkntfs as it stands now would create
> > Windows bootable partitions.
> >
> > The bad news is that Linux 2.4, HDIO_GETGEO ioctl returns wrong values
>
> You mean 2.6?
Yes, sorry, I do mean 2.6.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
On Mon, 2004-03-29 at 15:41, Andries Brouwer wrote:
> On Mon, Mar 29, 2004 at 03:48:01PM +0200, Szakacsits Szabolcs wrote:
> > On Mon, 29 Mar 2004, Anton Altaparmakov wrote:
> > > I have been experimenting a little with what Windows / Linux 2.4 / Linux
> > > 2.6 think the geometry of a couple of HDs is and the results are not
> > > very promising. )-:
> > >
> > > Using Linux 2.4, HDIO_GETGEO ioctl, I get the same Heads and Sectors per
> > > Track as Windows on both HDs I tried it on. This is the good news.
> > > I.e. at least on those two disks mkntfs as it stands now would create
> > > Windows bootable partitions.
> > >
> > > The bad news is that Linux 2.4, HDIO_GETGEO ioctl returns wrong values
> >
> > You mean 2.6? That's what I'm saying also for a while. It's a known issue
> > and people are complaining about it because kernel breaks things (e.g.
> > they can't boot anymore and think Linux thrashed their systems).
> >
> > I don't know who is the kernel maintainer today but apparently nobody.
> > Old maintainer, Andries Brouwer, only repeates that the geometry doesn't
> > exists even if he was/is proved and pointed out to be wrong many times.
> >
> > The issue was discussed long, several times on linux-kernel without a
> > satisfying solution.
>
> Well, to be more precise, my point of view is that roughly speaking
> (I know of some obscure exceptions) "geometry" does not play a role
> for Linux. Something entirely different is the use of other operating
> systems.
>
> What I also claim is that Linux has no way of knowing what geometry
> other operating systems will assign to a disk. Different operating
> systems invent different translations.
>
> Moreover, there is the matter of the correspondence of BIOS disk numbers
> and Linux disk names. Especially when both IDE and SCSI disks are present,
> and when more than two disks are present, it may be impossible to get
> this correspondence right. Details depend on the type of BIOS.
>
> So, I claim, until now the kernel attempted to do something, and it often
> worked, and it often failed.
>
> However, there is really no good reason why the kernel would try to guess
> at the geometry other systems like to see. For the past years, the main
> thing the kernel did was inferring the desired geometry from the partition
> table. But fdisk or LILO or whatever can do that as well. So, really
> no kernel help is needed.
>
> I say this every few months and have not ever seen a good reason why
> this code would have to be in the kernel.
>
> (In other words: please, never use HDIO_GETGEO, the kernel does not
> have an opinion anymore, and HDIO_GETGEO produces random results.
> Do as *fdisk does: get a geometry, if one is needed, from the
> partition table.)
I would rather not have to touch the partition table from within
mkntfs. But I guess I may have to do that in the end if there is no
other way. )-:
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
Andries Brouwer <[email protected]> writes:
> What I also claim is that Linux has no way of knowing what geometry
> other operating systems will assign to a disk. Different operating
> systems invent different translations.
The only one that matters is the one Windows expects. Which is the
same as what DOS uses. Which is the geometry from the "legacy INT13"
BIOS interface.
> Moreover, there is the matter of the correspondence of BIOS disk
> numbers and Linux disk names. Especially when both IDE and SCSI
> disks are present, and when more than two disks are present, it may
> be impossible to get this correspondence right. Details depend on
> the type of BIOS.
True, multiple disks pose a problem. But for some applications (e.g.,
mine), the only disk that matters is the boot device. And although it
is theoretically "impossible" to determine the Linux disk name for the
boot device, somehow this has not prevented millions of installations
of Linux boot loaders.
The vast majority of systems do not have very many drives. So it is
possible to take a pretty good guess about how they are named.
Also, a fully modern EDD BIOS *will* let you perform this mapping
reliably by giving you PCI bus and device numbers. The EDD module
exposes this information, provided your BIOS makes it available...
Unfortunately, few do (yet).
> However, there is really no good reason why the kernel would try to
> guess at the geometry other systems like to see.
I agree that such guessing is better left to userspace. But I
disagree about applications using HDIO_GETGEO. By writing to
/proc/ide/hda/settings, I can alter the values returned by HDIO_GETGEO
for IDE devices. This is exactly what I want to do: Set the geometry
which ALL applications use.
For non-IDE devices, HDIO_GETGEO already returns useful geometry (in
my experience). So it is a perfectly fine way for applications to
determine the disk geometry.
> For the past years, the main thing the kernel did was inferring the
> desired geometry from the partition table. But fdisk or LILO or
> whatever can do that as well. So, really no kernel help is needed.
This is completely useless for my application, which is to install an
OS for the first time.
> (And, you say, what if I am partitioning an empty disk to be used by
> DOS/Windows? There my stock answer "look at the partition table"
> fails, but there is some EDD stuff that could be used instead. Of
> course one should always use the FDISK of some operating system to
> create partitions for that operating system.)
But I *am* partitioning an empty disk, and I want to use Linux (see
http://unattended.sourceforge.net/).
And I do. See:
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.0/0269.html
Cheers!
- Pat