Date: Sun, 29 Jun 1997 19:19:00 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: abial@korin.warman.org.pl (Andrzej Bialecki) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Disk built-in hw cache Message-ID: <199706290949.TAA19003@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.NEB.3.95.970627113451.14546A-100000@korin.warman.org.pl> from Andrzej Bialecki at "Jun 27, 97 11:52:59 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706290949.TAA19003>