From owner-freebsd-stable Mon Nov 20 20:18: 9 2000 Delivered-To: freebsd-stable@freebsd.org Received: from freeway.dcfinc.com (cx74889-a.phnx3.az.home.com [24.1.193.157]) by hub.freebsd.org (Postfix) with ESMTP id 94AC237B4CF; Mon, 20 Nov 2000 20:18:06 -0800 (PST) Received: (from chad@localhost) by freeway.dcfinc.com (8.8.8/8.8.8) id VAA07691; Mon, 20 Nov 2000 21:17:48 -0700 (MST) (envelope-from chad) From: "Chad R. Larson" Message-Id: <200011210417.VAA07691@freeway.dcfinc.com> Subject: Re: Dangerously Dedicated In-Reply-To: from Roman Shterenzon at "Nov 20, 0 02:50:49 pm" To: roman@harmonic.co.il (Roman Shterenzon) Date: Mon, 20 Nov 2000 21:17:48 -0700 (MST) Cc: msmith@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Reply-To: chad@DCFinc.com Organization: DCF, Inc. X-O/S: FreeBSD 2.2.8-STABLE X-Unexpected: The Spanish Inquisition X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As I recall, Roman Shterenzon wrote: > This is a really long thread indeed. Yes, it is. It was last time, too. > Could someone sum it up, and say why the current way isn't good? As I understand it (and I'm sure someone will correct me): 1) The PC-BIOS uses a table embedded in the Master Boot Record (MBR) to locate the next layer of bootstrap code on the disk. This table is called the "partition" table by most non-UNIX documentation. FreeBSD calls it the "slice" table. FreeBSD doesn't use the BIOS for anything other than loading the bootstrap code, so all of this is only an issue early in the startup. 2) If you allow Microsoft's fdisk program to install an MBR, it builds one that wastes space. So do many other programs that try to perform the same function. The waste is caused, in part, by rounding a Logical Block Address (LBA) to a cylinder/head/sector (CHS) boundry at the end of the partitions, and reserving the first "track" on the drive. Since in modern drives, CHS and tracks are both fictional inventions (do you think your Segate Barracuda really has 63 heads?), some people are offended by the waste. Or, they're running from limited disk space such as memory cards or floppy disks and don't feel they can afford it. 4) "Dangerously Dedicated" (DD) disks do not have an MBR. Instead, the FreeBSD disk label (which contains the definition of what FreeBSD calls the partitions) sits where the MBR would have been. It has embedded in it a bogus slice table. This dummy table was sufficient to statisfy the BIOSs in general use at the time the code was written, since they only have to load the first block of the "active" slice and jump to it. 5) The BIOSs in some newer machines expect an actual, correct MBR. For example, the BIOS on a hardware RAID controller might get confused if all the drives attached to it don't have a "proper" MBR whilst trying to boot. 6) You can only generate a DD disk at system installation, or by using disklabel to hand-craft a partition table yourself. To summarize the summary: The problem comes from the fact that a PC-BIOS is permitted to insist on an MBR on each drive, and that the slices in that MBR align on certain boundries whereas FreeBSD doesn't care about such sillyness but has to use the BIOS to get launched. Simple solution? Don't use DD. Slightly less simple? Don't use DD on drives that are in any way involved with the boot process, but go ahead on data-only drives. If you fully understand your own hardware (many don't) and what it does at startup, go ahead and use DD. But don't expect to migrate the drive to some another system later and keep the data. Or to multi-boot several operating systems. My opinion? It would be good if the boot/disklabel/fdisk suite dealt with this cleaner. But unless you're jammed into it by tiny media or misbehavior on removable disks or something in that catagory, the space savings aren't worth it. > The sysinstall asks and warns about the "DD" mode, isn't that > sufficient? Apparently, not. -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? chad@dcfinc.com chad@larsons.org larson1@home.net DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message