Date: Thu, 28 Mar 1996 09:39:05 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: jerry@border.com Subject: Re: fdisk and partition info Message-ID: <199603280839.JAA23576@uriah.heep.sax.de> In-Reply-To: <199603271949.MAA01736@phaeton.artisoft.com> from "Terry Lambert" at Mar 27, 96 12:49:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > > All of it is for FreeBSD. When I do a 'fdisk wd0' > > it only reports 24MB.. Now then, can I assume the 24MB amount is due to > > the 1024 cylinder limit? Nope. This is due to a faked fdisk entry. The embedded fdisk table in the boot1 structure (see /sys/boot/biosboot/) faked a 50000 blocks BSD fdisk entry. Until very recently, ``disklabel -B'' was always clobbering the existing fdisk table when installing a new bootstrap. This left you with a dummy fdisk table (though the slice code knew about this one, and assumed a full BSD slice). If you didn't use a ``dangerously dedicated'' BSD slice, you might not have noticed this, since the BSD disklabel wasn't at offset 0 in the disk. Only for ``dangerously dedicated'', the BSD label is the MBR itself, hence the embedded fdisk table in the BSD label is of any interest. > 1) Assume the geometry is translated, and that it is > 1024/64/256. This is what the current FreeBSD slice > code does, much to the consternation of those of us > who own WD1007 or other non-translating controllers. This is not right. The FreeBSD kernel gets the BIOS geometry (for the first N BIOS drives) passed from the bootstrap. This might or might not be a `translated' one (though it's normally translated for all modern disks). The WD1007V *can* translate. It has a few hardware translation options. They were commonly used to remap drives with more than 1024 physical cylinders into the BIOS accessible range. (The geometry of ESDI drives usually could be expressed by a ``real'' CHS value, i.e. they didn't do any fancy Zone Bit Recording or other stuff all modern drives do.) The consternation does only result out of the usage of ``spare sectors'' at controller level on the WD1007V. Don't use them, and you should be going. (You can always use bad144 sector sparing, and if your drive exceeds 1024 cylinders from a BIOS point of view, you could handle this by using two BSD slices, where the first one is below 1024 and contains at least the root f/s.) > 2) Interpolate the geometry from an existing DOS partition > table, and the known rules of behaviour for the DOS fdisk > program. Specifically, starting and ending on cylinder > boundries, etc.. Since it is possible to have multiple That's what libdisk does. While this is a good idea for drives that do already have a DOS partition, it can cause some serious troubles for uninitialized disks (or disks with non-fdisk-table previous operating systems). This is what caused the ``You'd best install a DOS partition first'' attitude for FreeBSD 2.0.5. (And since this attitude deemed to be unacceptable for people who didn't wanna care about any DOS partition at all, since all they want is FreeBSD, this caused me to invent the ``dangerously dedicated'' mode of installation.) > geometries result in the same values, especially when you > have a small number of partitions (for instance, one), > this is not a 100% reliable approach -- in general, it is > so *unreliable* that the slice code was invented to replace > it. It's possible to "help" this approach be more accurate The slice code was invented to cover multiple fdisk slices at all, e.g. to handle more than one slice with a 0xa5 signature (though you can still only boot from the first one), or to handle ``DOS extended partitions''. > using the 32 bit absolute sector address, which is also in > the partition table. The problem with that is that older > FDISK programs did not generally fill out the 32 bit sector > offset correctly, so determining this information is usually > no more reliable if the offset happens to check a valid > geometry [NB: the FReeBSD FDISK should always fill these > fields out correctly in any case). fdisk did always fill out these parameters correctly (or at least, it told you about its idea before writing them to the disk, so you've been able to manually intervent if the idea was wrong). Only a ``disklabel -B'' installed a bogus fdisk table, see above. > 3) Ask the BIOS. There are several ways to do this: > b) Implement a multi-stage boot as opposed to a two > stage boot, ... Funny, our two-stage boot does already ask the BIOS, and pass these values to the kernel. UTST. (Use the source, Terry. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603280839.JAA23576>