Date: Wed, 31 Oct 2001 11:21:00 -0500 From: Bill Vermillion <bill@wjv.com> To: "Byan, Stephen" <Stephen_Byan@Maxtor.com> Cc: "'bv@wjv.com'" <bv@wjv.com>, Alexander Leidinger <Alexander@Leidinger.net>, tlambert2@mindspring.com, bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? Message-ID: <20011031112100.A82040@wjv.com> In-Reply-To: <378289F42B3FD51185AD0002B3302CF4091C7C@mmaexc01.mma.maxtor.com>; from Stephen_Byan@Maxtor.com on Wed, Oct 31, 2001 at 07:09:25AM -0800 References: <378289F42B3FD51185AD0002B3302CF4091C7C@mmaexc01.mma.maxtor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 31, 2001 at 07:09:25AM -0800, Byan, Stephen thus sprach: > > Bill Vermillion [mailto:bill@wjv.com] wrote: > > > If it is replaced by a spare, I didn't have a problem. I just > > > want to use the program to lookup files for which the error still > > > is present (in my particular situation there was a read error on > > > a file and I had to issue a write command to this block (with > > > camcontrol) to have it replaced with a spare). > > > > Properly set up you should not have to do this. > > If you drive supports relocation and it is turned on, some drives > > don't have it turned on, then all of this should be transparent > > > > ----------------- > > AWRE (Auto Write Reallocation Enbld): 1 <*************** > > ARRE (Auto Read Reallocation Enbld): 1 <*************** > > TB (Transfer Block): 1 > > RC (Read Continuous): 0 > > EER (Enable Early Recovery): 0 > > PER (Post Error): 1 > > DTE (Disable Transfer on Error): 0 > > DCR (Disable Correction): 0 > > Read Retry Count: 41 > > Correction Span: 48 > > Head Offset Count: 0 > > Data Strobe Offset Count: 0 > > Write Retry Count: 24 > > Recovery Time Limit: 65535 > > > > The AWRE and ARRE at 1 say to reallocate on errors. Since you > > mentioned you used camcontrol to fix this then use the modepage > > of camcontrol to see this. The above is page 1. > Setting ARRE (Auto Read Reallocation Enbld) only enables > reallocation on a recovered read error. If the read error is > unrecoverable, then the drive will not reallocate the LBA. Section > 7.1.3.7 of the ANSI SCSI-3 Block Commands (SBC) standard says > "[t]he automatic reallocation shall then be performaned only if > the device server successfully recovers the data". > On an unrecovered read error, simply writing the block is probably > not be enough to cause a spare sector to be reassigned to the LBA, > even if AWRE (Auto Write Reallocation Enbld) is set. The drive > does not read the sector before overwriting it, so it is unlikely > that the write will encounter the same fault that generated the > uncorrectable read error. > In general you have two options for "repairing" an uncorrectable > read error. Well I've only had one uncorrectable error. That was on a rack mounted SGI server - and someone had NOT bolted the rack down and someone tripped and the rack moved. > First, you can simply overwrite the sector with new data, without > reassigning the LBA to a spare sector, in the expectation that > the fault was not a media defect, but rather an off-track write. > Second, you can issue a REASSIGN BLOCK command, to cause the LBA > to be reassigned to a spare sector, followed by a WRITE. Without > the WRITE, the contents of the reassigned LBA are unspecified, and > reading that LBA may result in an unrecoverable read error. Nothing I've used falls in that area - all Unix systems an all SCSI. > Theoretically, all media faults have been mapped out during the > drive manufacturing process, and there should be no "grown" > defects, so in most cases the source of the uncorrectable read > error is data that was written off-track, or interference from > data for a neighboring track that was written off-track. Well I've had grown defects in the past - none in the EIDE arena but in the SCSI world. At times I think I've been playing with these beasts too long. > In real life, some media defects may escape detection during the > factory media scan. In this case, reassigning the LBA to a spare > sector is the correct recovery action. And I've never had anything fail to do that, except the SGI and the xfs file system doesn't give you a lot of lee-way in correcting those. The only possible action there, and is documented as such, is to remake the file system. I'd use the low-level format routines, where you could set the way the buffers were allocated, etc, and manipulate drive as the lowest level. I'd basically re-QC the drive to remap all areas. > Another possibility is that the media defect is truly a grown > defect, i.e. a result of a head crash or other particulate > contamination in the drive. In this case, expect a growing cascade > of hard read errors over time. The correct recovery action is to > backup what data is readable, replace the drive, and restore from > your backup media. Yup. I've seen that. But guess what - in most cases I've not replaced the drive. There is a old believe that one failure is just a pre-cursor to many. Much of this started in the days of coated media and often a bit could flake off. And this flake could get under heads or elsewhere, and it could just cascade. With the advent of plated media this is not neccesarily true. Often a bad area is nothing more than a marginal area in the coating that did not show up in the first place and was not mapped out during manufacture. There was also the old adage about reformatting your drive to 'refresh' the media - but I think that was more attributeable to the wear associated in the days of drives with stepper motors where the mechanisms could wear and track alignment could occur and a reformat cured that. Then the dedicated servo took over, and with the embedded servo that's something we don't have to worry about any more, at least not as I see it. > Speaking for myself, not Maxtor, I recommend the following error > handling policy: > 1) on the first occurrance of an uncorrectable read error for an LBA, > rewrite the block without reassigning the LBA to a spare. > 2) on the second occurrance of an uncorrectable read error for an LBA, > reassign the LBA to a spare and rewrite the block. > 3) if a high frequency of uncorrectable read errors on varying > LBA's occurs, alert the operator to take immediate preventive > maintenance action, by initiating a backup, drive replacement, and > restore. The SMART failure prediction algorithms in the drive may > be sufficient to detect and report this case, but I'm not familiar > enough with them to state that with certainty. Well in "The Goode Olde Dayze" <TM pending> :-) I got a Maxtor ESDI - this was when the battle was between ESDI and SCSI and no one was sure what would survive - I wound up with an Maxtor at a reasonable price - $1300 for 600+MB - about $400 off because the bad track list was over 300 - the maxium acceptable for a new drive. I put it in service. Formatted with altnerate sector replacement, so that if a sector went bad ECC kicked in, reread the data, reformatted the track with the bad sector as sector 0 [thus unseeable] rewrote the data an continued on. If I got more than one bad sector the track was reallocated. The system was in a desk side tower - and it did get bumped now and then :-(. Sometimes no problem - other times you would see some re-mapping. This was a very active system as a news-node. After a few years and it was still going I decided to see how long it would go. At about the 6th year it ran out of free tracks to reallocate. At the end of seven years, 2 months and 2 weeks the system failed, and it was most probably the controller as floppy access - also on the controller - had gotten bad too. I see re-write/re-map on some SCSI drives too [not Maxtor/Quantum] and they are due for replacement soon - as their size and age [running 24x7 for five years] make replacement recommended. > If you happen to have a recent Maxtor (aka Quantum) SCSI drive, > if you set the Reallocate Uncorrected Errors bit (byte 2 bit 4) > on the Maxtor-unique mode page (mode page 39h), you will get > approximately the above algorithm. From the Atlas 10K III Product > Manual, Publication Number 81-126196-01: Thanks for that information. I recall that a very long time ago the number of bits for ECC was settable somewhere deep down inside the drive - is this the case anymore. I'm just asking this out of curiousity. > "When this field = 1, a block that encounters an uncorrectable > read error will be marked for pending reallocation. The block in > error remains "as is" for a possible recovery on a future access. > If a subsequent successful read or write (with readback / compare) > occur, the pending reallocation will be deferred. However, it > will be "remembered" that an unrecoverable read occurred at > one time, and if a second unrecoverable read occurs, the block > will be reallocated on the next successful access. Also, if a > subsequent unsuccessful write occurs on a block marked for pending > reallocation, the block will be reallocated." Now that is a much better approach than the old way. I'm constantly amazed by the progress the HD industry is making. > The "remembering" is persistent across power-cycles. You'll need > to re-write the block to remove the uncorrectable read error > - when the drive reallocates an uncorrectable read error, it > marks the new sector as containing bad data, and will return an > uncorrectable read error until that LBA is overwritten. Thanks for the details. As I say I'd never had any problems with re-writing anything automagically except the reall hard error on the SGI. That required going to the low-level format routine. Now that was interesting as the right move in the wrong place could mean that drive would not work again until it went back to it's manufacturer. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011031112100.A82040>