From owner-freebsd-hackers Thu Feb 4 19:50:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18898 for freebsd-hackers-outgoing; Thu, 4 Feb 1999 19:50:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18889 for ; Thu, 4 Feb 1999 19:50:24 -0800 (PST) (envelope-from tony@dell.com) Received: from moth (moth.us.dell.com [143.166.169.152]) by bugs.us.dell.com (8.8.8/8.8.8) with SMTP id VAA06949; Thu, 4 Feb 1999 21:49:51 -0600 (CST) (envelope-from tony@dell.com) Message-Id: <3.0.6.32.19990204214937.00879b20@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 21:49:37 -0600 To: Avalon Books From: Tony Overfield Subject: Re: Unable to newfs HD >10G with 3.0 Cc: FreeBSD Hackers In-Reply-To: References: <3.0.6.32.19990204131321.00793ec0@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:00 PM 2/4/99 -0600, Avalon Books wrote: > Perhaps some clarifications are in order... > >On Thu, 4 Feb 1999, Tony Overfield wrote: >> 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. Well, have you seen a "newer PC" that doesn't implement INT 13 extensions, or are you confusing what I said with some other problem that you've seen? >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. Heh, same here, among other things. >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. I was assuming the devices are not known to be defective. All bets are off for any *standardized* behavior of broken devices. > 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... Then they must have really bunged it up. I've not seen such a problem with any of the drive suppliers we use. >> > 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 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. There's no excuse for busted drive firmware, but you can't blame the "8.4 GB solution" which, as I said, works correctly if implemented properly. You implied that there are a bunch of nonstandard solutions to this problem, but that isn't true. I don't consider a bug in a particular drive's firmware to constitute a "nonstandard implementation." In my mind, and probably yours too, it is simply broken and needs to be replaced. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message