From owner-freebsd-hackers Sun Jun 29 02:49:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA25685 for hackers-outgoing; Sun, 29 Jun 1997 02:49:24 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA25680 for ; Sun, 29 Jun 1997 02:49:19 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id TAA19003; Sun, 29 Jun 1997 19:19:01 +0930 (CST) From: Michael Smith Message-Id: <199706290949.TAA19003@genesis.atrad.adelaide.edu.au> Subject: Re: Disk built-in hw cache In-Reply-To: from Andrzej Bialecki at "Jun 27, 97 11:52:59 am" To: abial@korin.warman.org.pl (Andrzej Bialecki) Date: Sun, 29 Jun 1997 19:19:00 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrzej Bialecki stands accused of saying: > > > I just read certain discussion on Linux list concerning > > > bad/missing/removed disk cache in "repaired" (and sold as new) hard disks. > > > Linux prints during probing the size of disk cache (at least that what the ... > > Uhh, this sounds pretty bogus. Do you have a reference to anything > > authoratative on the subject? > > No :-(. AFAIR from that discussion, IDE disks answer certain query by > returning the info stored somwhere on cyl 0. How this info relates to > reality is of course highly disputable (unless there are any specs on > this). How it gets updated if the chip gets bad/missing is similarly > vague. I think Bruce has sunk this one fairly categorically. > > size using a vendor-specific command, but the thought of "removing" > > the cache memory from a repaired disk is laughable. The PCBA on a > > modern disk is worth no more than a few dollars; the _only_ economical > > means for "reapairing" it would be to throw it away and replace it. > > Except when it is done by home-grown expert, and then sold as new or > a bargain. This is a joke, right? You rip the cache RAM (not what one would call an unreliable component, really) off the PCBA on the bottom of the drive, and expect the firmware and/or the bus interface controller to keep working? No, I don't think so. I'm inclined to go with Bruce on this one in that the Linuxers were panicking at nothing; it's possible the vendor decided that they didn't want the buffer size reported in one particular firmware revision, or that the buffer size was variable and thus couldn't be usefully reported, or something like that. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[