This message is from the T13 list server.
Raymond, You don't understand how auto reallocate works. It has nothing to do with error reporting. When a drive thinks that the media in question is suspect, it "auto reallocates" the data to another portion of media. If the data was readable, then the data is moved at that point. If not, then the drive remembers that the media is suspect and writes the data to the new section of media when it gets the next write command. The drives decision may be correlated to reporting an error to the host, but may not be. As an example, a drive could be performing a background scan of the media during idle time, run into that sector, and at that time determine that the media is suspect. The key is that none of this is standardized. To my knowledge once a drive decides to reallocate, that is a non reversible decision - you just used up a spare sector on the drive. Do that often enough and the drive will fail (there are a limited number of spares). Jim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 2:12 PM To: [EMAIL PROTECTED] Subject: RE: [t13] RAID and R/W LONG This message is from the T13 list server. Logically, the drive should not auto-reallocate when they encounter a read error, otherwise, the host might read a junk data and get "good status" back. It is not desirable but acceptable to get a read error (that is why people use RAID to prevent that), but it is not acceptable that the drive output the wrong data and tell the host it is good. This is data corruption (instead of data error). Raymond Liu -----Original Message----- From: McGrath, Jim [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 1:40 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: [t13] RAID and R/W LONG This message is from the T13 list server. The issue on auto reallocation may be that some implementations would auto reallocate on the subsequent READ of the sector. The drive has no way of knowing that this is a "good" sector that you artificially forced an error into. In general the details of auto reallocation policy are all vendor specific. Jim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [t13] RAID and R/W LONG This message is from the T13 list server. Creat a false uncorrectable error is only done in the very beginning of using the drive as RAID1 rebuild target drive (and only if necessary, i.e. only when the source drive has reported an unrecoverable data block). It might affect the statistical data the drive collected a little bit (only the drive guys can answer this). Auto-relocation should not be affected because this is not a normal write error. Raymond Liu -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 10:02 AM To: T13 List Server Subject: [t13] RAID and R/W LONG This message is from the T13 list server. On Thu, 21 Mar 2002 09:18:13 -0800, [EMAIL PROTECTED] wrote: >This message is from the T13 list server. >[...] you might implement >vendor specific commands to "address" that >(which will keep the R/W Long >still formally in "obsolete" state)? Raymond, I think I asked a few days ago, but could you explain in detail why/how you are using R/W LONG? Do you expect the command to actually be passed to a drive behind a RAID controller or is the command executed directly and only by the RAID controller? If the command is used to create a false uncorrectable error on a real drive, how do you then adjust for the possible effects on the drive's SMART data or the drives auto-relocation function? *** Hale Landis *** www.ata-atapi.com ***
