Date: Tue, 6 Jun 1995 12:46:52 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: taob@gate.sinica.edu.tw, freebsd-hackers@freebsd.org Subject: Re: Quantum hardware errors (Deferred Error: HARDWARE FAILURE asc:87,0) Message-ID: <199506061646.MAA17761@hda.com> In-Reply-To: <199506061618.JAA26313@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jun 6, 95 09:18:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
Rodney W. Grimes writes: > > > > > Brian Tao writes: > > No, this is not true. Have you studied the exact mechanism used to > do this in the drive. Studied it? No, but I do recall now that some drives do this. My blanket statement to turn off write cacheing is hereby rescinded. > They use the inertial energy of the rotating > disk to turn the spindle motor into a generator in case of power > failure and can actually write the cache after power goes down. You > only cache on cyclinder data in the write behind buffers so you don't > need the energy to do a seek. OK, I was just going to ask about seeks, and write failures during this power fail (though they are too infrequent to worry about). (...) > > Wrong, or at least wrong for Quantum drives, been running them that > way for 3 years in mass quantities (every Quantum drive shipped has > this turned on as far as I know) and never seen a data loss that you > could attribute to a write behind cache deferment. AWRE should > correct the problem if it could not write the data due to a sector > going bad... I thought about this, and decided it wasn't safe due to the power fail issue. For example, I can turn write cacheing on on my Fujitsu drives. Should I? I'm not going to. > > Be sure you also have Automatic Write Reallocation Enabled and > > Automatic Read Reallocation Enabled in mode page 1. > > This is true, and most manufacutres ship the drives with these > off. Including Quantum. Though I actually make sure it is off > before burn in testing, and then turn it back on at the end > of burn in. This is to watch for growing defects on new drives > that I want to know about. Any drive that grows an error this > early in it's life is returned to the manufature as a DOA drive. > [And yes, I have returned a few, very few, but even 1 counts in > my books as a significant reduction in user risk of reliability.] It is interesting that these are off in the default page 1, at least on the Fujitsu drives. > > The nature of the deferred error is that the OS thought the write > > succeeded and then later on reports back an error (in this case, > > it said the write succeeded when it cached the data on the disk, > > and then reported the failure when it couldn't transfer the cache > > to disk for some reason). > > I suspect turning on AWRE and running a verify operation on this > disk would clean the persons problem if this infact is what is > causing it. Also dump the growing defect list, you may have a > zone that has no more spares left in it due to lots of grown > defects :-(. > > > In 2.1 the system will sanity check the mode page settings during > > boot and will comment on anything it thinks is set wrong. > > Great, and just what are the ``sanity'' values going to be?? I planned on AWRE and ARRE. I would have added this at the same time as I added the mode editor if it weren't for the code freeze. I was planning on warning about write cacheing, but apparently that is a bad idea. I could check the default page and the current page and warn if write cacheing is enabled in current and disabled in default. A little thing like that that isn't too hard to do would impress me when I switched to FreeBSD - I'd have been thrilled to have the new OS point out that my disk may be configured wrong. > > > I then used "scsi -f /dev/rsd2.ctl -m 8 -e -P 3" to turn off > > > write-cache enable. The minimum pre-fetch on my drive was set to 8, > > > but I noticed yours is 0. I suppose this value means the drive will > > > always try to grab 8 blocks at once? It is set to 0 now, to match > > > yours, if it makes any difference. > > > > Mine may not be correct; it is just set as the vendor shipped it. > > Quantum may have some reason they want the drives set that way. > > You just killed the read ahead cache in the drive, this man adversely > effect performance. I suggest you reset it to what the drive says > the default value is (-P 4??). -P 2. Except that it is the "minimum" pre-fetch, so I'm not sure what it means or what he did to performance. I wouldn't change it from the default. Just read back your default settings with "scsi -f /dev/rsd2.ctl -m 8 -P 2" and then edit it into your saved page (-P 3 -e). Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506061646.MAA17761>