From owner-freebsd-hackers Thu Feb 4 19:00:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11984 for freebsd-hackers-outgoing; Thu, 4 Feb 1999 19:00:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vespucci.advicom.net (vespucci.advicom.net [199.170.120.42]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11976 for ; Thu, 4 Feb 1999 19:00:39 -0800 (PST) (envelope-from avalon@vespucci.advicom.net) Received: from localhost (avalon@localhost) by vespucci.advicom.net (8.8.8/8.8.5) with ESMTP id VAA29248; Thu, 4 Feb 1999 21:00:35 -0600 (CST) X-Envelope-Recipient: freebsd-hackers@FreeBSD.ORG Date: Thu, 4 Feb 1999 21:00:35 -0600 (CST) From: Avalon Books To: Tony Overfield cc: FreeBSD Hackers Subject: Re: Unable to newfs HD >10G with 3.0 In-Reply-To: <3.0.6.32.19990204131321.00793ec0@bugs.us.dell.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Perhaps some clarifications are in order... On Thu, 4 Feb 1999, Tony Overfield wrote: > At 08:35 PM 2/3/99 -0600, Avalon Books wrote: > > However. EIDE itself is another matter. Based on drive geometry and > >sector addressing limitation, the official EIDE spec ends around 8.4 > >Gbytes > > This is true. > > >--anything bigger than that is a non-standard implementation. > > This is false. All newer PC's implement the same INT 13 BIOS extensions > to get around the original INT 13 BIOS's 8.4 GB limitation. I beg to differ. PC hardware is what I do for a living, and this 8.4 Gbyte *standard* is a big deal to my state, federal and institutional contracts. For these non-standard implementations to be accepted, we have to jump though extra hoops (i.e. testing). Its rarely a problem to get them accepted as only a few BIOS's/drive firmware's are behind the curve so far as to fail our testing. > >Note > >that most of the newer PC's don't seem to have much problem with this at > >the hardware level, and most of these non-standard drive appear to work > >as advertised. > > The newer PC's work fine because they all implement the same spec to solve > the problem. There isn't a problem at the hardware level either because > nothing has changed at the hardware level to support more than 8.4 GB. > Essentially correct. To the BIOS, its just another big block device. But getting that block device to translate into a useable form has had its problems. Ask Fujitsu and Samsung about the firmware nightmare they went through last year... > > Operating systems don't think that some of these non-standard > >implementations are very funny, as turning a hard drive into a large > >number of blocks into a logical volume is not as easy as it sounds, and > >this can be made much more difficult when manufacturers start cutting > >corners on drive firmware... > > This makes no sense. Most older operating systems do not support the > BIOS extensions, but that's simply because they need to be updated, > not because anything funny is going on. Once the OS is booted, it's > up to the OS to support the drive's capacity, and nothing funny needs > to happen there either, until we get past 137 GB, which should happen > within a few years. This makes perfect sense. We have a great deal more trouble from idiosyncratic drive firmware than motherboard BIOS's. Sometimes things just don't translate like they should, and the O/S's have no choice but to "give up" on a drive with broken firmware. Its not the O/S's fault, of course, but all you can do is swap the drive for one that works properly. --R. Pelletier Sys Admin, House Galiagante We are a Micro$oft-free site To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message