Messages in this thread | | | Date | Sat, 23 Oct 1999 14:43:05 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: [Fwd: Hard disk geometry] |
| |
From clausen@alphalink.com.au Sat Oct 23 06:33:50 1999
CC: parted@gnu.org Subject: Re: [Fwd: Hard disk geometry] References: <UTC199910221059.MAA16257.aeb@korhoen.cwi.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Andries.Brouwer@cwi.nl wrote: > With Windows things are less simple. It knows about disk translation > schemes, and has new partition types indicating that extd int 13 is > used and geometry is meaningless.
Don't forget that Windows is essentially DOS. When you boot in MS-DOS mode, you have the system that Windows bootstraps itself with.
I did not forget anything. My statement stands.
> If you know that no other fdisk-type program than DOS FDISK > has ever touched the partition table, then probably partitions > end at cylinder boundaries. But if for example Linux or SCO software > has created partitions then there is no guarantee for this to be true.
Linux fdisk will only let you break these rules in expert mode.
Linux has fdisk, cfdisk, sfdisk, Disk Druid, fips, and more.
> And even if only DOS FDISK has been used but the disk was moved > between computers, or within one computer between SCSI controllers, > it may be false.
Really?!?! I'd imagine the DOS MBR code uses the CHS locations of partitions to determine where to find the boot sector. If what you said is true, a hard disk that can bootstrap on one machine can't on another.
Yes, and that is precisely how it is.
I guess I should check if the DOS/Windows MBR uses LBA or CHS to find the boot sector.
The classical DOS MBR uses CHS, of course. > It seems the hard disk's actual geometry, and the geometry as DOS > sees it are two different things. > > There is no actual geometry.
Don't hard drives have a defined number of heads, and a defined number of tracks per head, and sectors per track? Even if software can't determine it, it is defined.
No. The number of sectors per track is variable - on the outer tracks there are often twice as many sectors as on the inner tracks. And this number is often a few hundred. So: 1. There is no actual geometry. And 2. Even if you succeed in finding out the hardware details you'll get information that could not be used because S is a 6-bit number, at most 63.
> Yes, if possible. But in a Linux context you'll find that most > disks are unknown to the BIOS - many people only put their boot > disk in the BIOS setup.
If the hard disk doesn't have a geometry defined by the BIOS, then Linux can't get it. But then, DOS can't either. So what on earth does DOS do, (assuming it's using CHS, not LBA)?
DOS doesnt see it, I suppose.
Could you use the v3.0 BIOS standard's interface and device path, mentioned in Ralf Brown's intlist?
Few machines today support this. My latest machine is only two months old and has no such support. No, there is not really any reason to involve the BIOS. Anyway, it seems the solution is to always write out partition tables with LBA partitions, not CHS. It seems we don't need to care about aligning partitions to cylinder boundaries, so there's no need for geometry at all, for Windows 95 and up.
*BUT*, does anyone know if the Win 95 LBA partition type was introduced in the original release?
Types e and f are from W95. Types b and c from W95 OSR2.
I wrote several informative texts about such things, and your mail suggests that you never saw these. Look at
http://www.win.tue.nl/~aeb/partitions/partition_types.html and http://www.win.tue.nl/~aeb/partitions/partition_tables.html and http://www.win.tue.nl/~aeb/linux/Large-Disk.html
Comments, additions and corrections are welcome.
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.tux.org/lkml/
| |