* Re: [Linux-NTFS-Dev] Geometry determination [not found] <1080564842.5545.19.camel@imp.csi.cam.ac.uk> @ 2004-03-29 13:48 ` Szakacsits Szabolcs 2004-03-29 14:41 ` Andries Brouwer 2004-03-29 14:57 ` Anton Altaparmakov 0 siblings, 2 replies; 5+ messages in thread From: Szakacsits Szabolcs @ 2004-03-29 13:48 UTC (permalink / raw) To: Anton Altaparmakov; +Cc: ntfs-dev, Andries Brouwer, linux-kernel 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Linux-NTFS-Dev] Geometry determination 2004-03-29 13:48 ` [Linux-NTFS-Dev] Geometry determination Szakacsits Szabolcs @ 2004-03-29 14:41 ` Andries Brouwer 2004-03-29 15:02 ` Anton Altaparmakov 2004-04-01 23:06 ` Patrick J. LoPresti 2004-03-29 14:57 ` Anton Altaparmakov 1 sibling, 2 replies; 5+ messages in thread From: Andries Brouwer @ 2004-03-29 14:41 UTC (permalink / raw) To: Szakacsits Szabolcs Cc: Anton Altaparmakov, ntfs-dev, Andries Brouwer, linux-kernel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Linux-NTFS-Dev] Geometry determination 2004-03-29 14:41 ` Andries Brouwer @ 2004-03-29 15:02 ` Anton Altaparmakov 2004-04-01 23:06 ` Patrick J. LoPresti 1 sibling, 0 replies; 5+ messages in thread From: Anton Altaparmakov @ 2004-03-29 15:02 UTC (permalink / raw) To: Andries Brouwer; +Cc: Szakacsits Szabolcs, ntfs-dev, linux-kernel 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Linux-NTFS-Dev] Geometry determination 2004-03-29 14:41 ` Andries Brouwer 2004-03-29 15:02 ` Anton Altaparmakov @ 2004-04-01 23:06 ` Patrick J. LoPresti 1 sibling, 0 replies; 5+ messages in thread From: Patrick J. LoPresti @ 2004-04-01 23:06 UTC (permalink / raw) To: Andries Brouwer Cc: Anton Altaparmakov, ntfs-dev, Andries Brouwer, linux-kernel Andries Brouwer <Andries.Brouwer@cwi.nl> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Linux-NTFS-Dev] Geometry determination 2004-03-29 13:48 ` [Linux-NTFS-Dev] Geometry determination Szakacsits Szabolcs 2004-03-29 14:41 ` Andries Brouwer @ 2004-03-29 14:57 ` Anton Altaparmakov 1 sibling, 0 replies; 5+ messages in thread From: Anton Altaparmakov @ 2004-03-29 14:57 UTC (permalink / raw) To: Szakacsits Szabolcs; +Cc: ntfs-dev, Andries Brouwer, linux-kernel 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-04-01 23:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1080564842.5545.19.camel@imp.csi.cam.ac.uk>
2004-03-29 13:48 ` [Linux-NTFS-Dev] Geometry determination Szakacsits Szabolcs
2004-03-29 14:41 ` Andries Brouwer
2004-03-29 15:02 ` Anton Altaparmakov
2004-04-01 23:06 ` Patrick J. LoPresti
2004-03-29 14:57 ` Anton Altaparmakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox