From owner-freebsd-current@FreeBSD.ORG Tue Aug 12 17:19:57 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935F237B411 for ; Tue, 12 Aug 2003 17:19:57 -0700 (PDT) Received: from papoose.quick.com (papoose.quick.com [199.120.187.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E0E243F75 for ; Tue, 12 Aug 2003 17:19:52 -0700 (PDT) (envelope-from jq@quick.com) Received: from quick.com (lili.chezq.com [199.120.187.254]) by papoose.quick.com (8.12.9/8.12.9) with ESMTP id h7D0JmBB068381 for ; Tue, 12 Aug 2003 20:19:48 -0400 (EDT) (envelope-from jq@quick.com) Date: Tue, 12 Aug 2003 20:19:45 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: James Quick To: current@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030811223022.21bfb3df.dmp@bitfreak.org> Message-Id: X-Mailer: Apple Mail (2.552) Subject: What parts of disk geometry are relevant? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 00:19:58 -0000 I'm setting up 5.1 with a couple of new drives. Sysinstall, and for that matter, any combination of command line tools, all seem have different ideas about geometry. Sysinstall would use any of the numbers I threw at it, and even after using sysinstalls values, fdisk and bsdlabel find reasons to gripe. Configuration data: The geometry from the manufacturers docs, which is reported several times at boot, is: 152627MB [310101/16/63]. The geometry mandated by sysinstall is: 19475/255/63 (The drive physically has 2 platters and 4 heads - but at least 16 is a multiple of that) Both sysinstall-help and most of my web research says that the way to be sure about what to use is to boot to dos or windows and see what it says. That is hardly convenient as my only use of Intel based systems has been confined to {NeXT,Open}Step and now FreeBSD. What does DOS know that FreeBSD doesn't? I'm migrating from a 2+ year old 5.0 installation, which is in production use, so I don't have the luxury of just playing with the parameters to see what boots and what doesn't. As far as compatilbilty goes, I need 5.x BootEasy, the loader, and the kernel to be happy about all the slices+partitions on the drive. If there is any difference, Compatibility with 4.x as well would be nice but is not required. I'll ask two questions first, since yes answers will relegate the others to matters of idle curiosity. 1. If newfs succeeds for a ufs2 partitions extending beyond 120GB, does that mean the configuration is OK? 2. Is sysinstall's cryptic refusal to use the reported values, (and astoundingly poor choice of alternate values), solely to ensure that Wintel OSes sharing the drive don't get confused? (c'mon 255 heads? And don;t get me started about a cylinder size whose factors are all prime!!) If the answer to either of those is no, I would appreciate further clarification. The rest of my confusion surrounds related issues of geometry, and whether or not they are important, or irrelevant. The original design of ffs/ufs mkfs was heavily dependent on geometry for performance and reliability. These are memories from v7, but I seem to recall that rpm, skew factors and interleave were important, and that incorrect vs. correct values had significant impact on both performance and reliability. bsdlabel -A reports 3600 for rpm (a very old default) interleave is 1, and the rest are 0. Are these just legacy structures on disk, or is anyone paying attention to them? Fdisk reports cylinder numbers which obviously depend on the geometry used when the partition (slice) was written. It always complains that the in-core disk label will not work beyond cylinder 1. Is this more pandering to DOS or can I ignore it? Bsdlabel complains about c partitions not covering the whole unit. I checked and found that sizes of all defined partitions sum to c, and that the size of c equals the size of the slice reported by fdisk. I checked the code, and it seems to be saying that by 'c' partition in a slice doesn't cover the whole drive. In that case, the warning just seems out of place. Is that what's going on?