Date: Sun, 31 Mar 1996 14:06:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org Subject: Re: fdisk and partition info Message-ID: <199603312106.OAA11874@phaeton.artisoft.com> In-Reply-To: <199603302236.XAA04909@uriah.heep.sax.de> from "J Wunsch" at Mar 30, 96 11:36:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > "Dangerously dedidcated" is a misnomer. I've always found it annoying. > > > > What it means is that the second stage (BSD) boot is put in place of > > the MBR. For WD1007 with > 1024 cylinders, this shoots down the > > "use two partitions to make Bad144 happy with the boot disk" idea > > That's why it is called ``dangerously'' dedicated: it becomes > dangerous for people who don't know what they are doing. It's also dangerous for people who know what they are doing, since the second stage's (now the MBR's) BIOS-using boot code can still only access 1024 cylinders. The problem is introduced because Bad144 is broken. That is, it is not intrinsically dangerous to dedicate the disk, it is only intrinsically dangeous to use Bad144 media perfection as it currently exists. And there are some technological barriers that must be penetrated to make bad144 other than as it currently exists -- although, as shown below, a kludge could be provided and is not being provided. > > you put forth above (note: this should work, there's no technical > > ambiguity preventing it from working, but the current code doesn't > > handle that case). > > Nobody except Terry L. seems to be that much interested in improving > support for rather obsolete controllers. Terry L. doesn't seem to be > that much interested in modifying the bad144 code to do what he would > like to see. The net effect is that nobody changes the bad144 code. This is not true. I believe that Bad144 processing (media perfection) needs to be moved out of the physical driver altogether and relegated to a layer below that used to translate BSD disk labels. For me to be able to make this to happen, FreeBSD needs to move to an integral devfs. And you will note, I have been arguing long and hard for a devfs (since early 1994). You may have missed this because of the suggested change to the Bad144 table location to just before the swap area I have made previously. If it wasn't clear then, I will make it clear now: this is a kludge soloution wich is a poor substitute for a real soloution, but which would result in making it work *now* for people with orphaned hardware. If you truly did not care about orphan hardware or antiquated DOS fdisk programs, then you would write a DOS MBR capable of booting DOS, etc, that uses the 32 bit sector offset and was LBA capable, since the only thing preventing that from happening is historical interoperability with what I would consider to be "orphan hardware that just doesn't know it yet". The correct soloution involves removing the bad144 code from the disk driver itself to divorce it from the disk driver level so that it can be applied to things like spanned volumes, etc.. Like a spindle-synced striping system, etc., which can not have the disk location translated out from under it because of seek latency throwing off read sync. To do this requires the ability to transparently reexport a device node given a device node and on disk tag information indicating bad144 media perfection should be applied and the device reexported. This necessarily involves a boot code change at the same time. Help me lobby for getting the devfs code in place, and help me lobby for a hierarchical devfs layout (even if the resulting exposed namespace is flat, like Bruce wants), and help abstract the boot code into multiple stages, and I will be happy to write the boot modifications and the logical-to-logical device driver that gets called back by the device registration process to cause "bad144" media perfection that doesn't blow chunks when the BSD DOS partition spans the 1024 cylinder boundry, but that 'a' slice of that partition (containing the kernel image) does not. > > > > 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 > ^^^^^^^^^^^^^^^^^^^^^ > > > No. I know for a fact that at lease some versions of DOS 2.11 and > ^^^^^^^^^^^^^^^^^^^^ > > prior did not fill out the 32 bit sector offset field correctly. > > Leading Edge was one of the offenders here. > > Do you realize your problem? You claimed that FreeBSD fdisk should > fill these fields correctly, i responded that it does, and you're > arguing that some 100-year old DOS fdisk didn't. Sorry, i cannot > follow you. I claimed, up front, that this is an interoperability issue with DOS. You may only safely use the 32 bit sector offsets if the OS's with which you are attempting to coexist do the same. Demonstrably, they do not. The FreeBSD 32 bit sector offset is not in question. The FreeBSD C/H/S values are. FreeBSD can not create a partition with a correct sector offset *AND* a correct C/H/S value because FreeBSD can not *know* the geometry that must be used to calculate the C/H/S values for a partition table from the correct sector offset. Further, FreeBSD can not know the correct sector offset in the first place, since if it is being installed on a disk with an existing real mode (C/H/S, INT 13 using) OS, that OS will not be guaranteed to fill in the 32 bit sector offset because it has not, historically, been required to do so by the DOS MBR, which reads the embedded partition table information for the DOS partition table. The complete context for the message from which the original quoted statement above is: ] 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 ] 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 ] 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). That is, the statement taken out of context to refer to the FreeBSD FDISK program, in fact refers to older DOS FDISK programs, and is simply an aside stating that I believe that historical brokenness is no excuse for intentionally breaking new code. Note the word "should". I believe the communication problem is that we've (stupidly) called the FreeBSD utility "fdisk" when it can not do what the DOS "fdisk" can do: fill out C/H/S values for a given drive ID based on the result of an INT 13 AH=8 call for that drive ID. And so it can not know the translation in the BIOS, the translation in an OnTrack Disk Manager (or other) LBA-using TSR, or the translation differential for multiple direves that can result from different BIOS settings on multiple controllers as a result of INT 13 chaining. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603312106.OAA11874>