Re: end to end error recovery musings

[Douglas Gilbert]

Martin K. Petersen wrote:
 Alan == Alan  [EMAIL PROTECTED] writes:
 
 Not sure you're up-to-date on the T10 data integrity feature.
 Essentially it's an extension of the 520 byte sectors common in
 disk
 
 [...]
 
 Alan but here's a minor bit of passing bad news - quite a few older
 Alan ATA controllers can't issue DMA transfers that are not a
 Alan multiple of 512 bytes without crapping themselves (eg
 Alan READ_LONG). Guess we may need to add
 Alan ap- i_do_not_suck or similar 8)
 
 I'm afraid it stops even before you get that far.  There doesn't seem
 to be any interest in adopting the Data Integrity Feature (or anything
 similar) in the ATA camp.  So for now it's a SCSI-only thing.
 
 I encourage people to lean on their favorite disk manufacturer.  This
 would be a great feature to have on SATA too...

Martin,
SCSI to ATA Translation (SAT) is now a standard
(ANSI INCITS 431-2007) [and libata is somewhat
short of compliance].

Work on SAT-2 is now underway and one of the agenda
items is end to end data protection and is in the
hands of the t13 ATA8-ACS technical editor. So it
looks like data integrity is on the radar in the SATA
world.

See http://www.t10.org/ftp/t10/document.06/06-497r4.pdf
for more evidence of how SAS and SATA are converging
at the command and feature set level.

Doug Gilbert


-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: end to end error recovery musings

[Douglas Gilbert]

H. Peter Anvin wrote:
 Ric Wheeler wrote:

 We still have the following challenges:

(1) read-ahead often means that we will  retry every bad sector at
 least twice from the file system level. The first time, the fs read
 ahead request triggers a speculative read that includes the bad sector
 (triggering the error handling mechanisms) right before the real
 application triggers a read does the same thing.  Not sure what the
 answer is here since read-ahead is obviously a huge win in the normal
 case.

 
 Probably the only sane thing to do is to remember the bad sectors and
 avoid attempting reading them; that would mean marking automatic
 versus explicitly requested requests to determine whether or not to
 filter them against a list of discovered bad blocks.

Some disks are doing their own read-ahead in the form
of a background media scan. Scans are done on request or
periodically (e.g. once per day or once per week) and we
have tools that can fetch the scan results from a disk
(e.g. a list of unreadable sectors). What we don't have
is any way to feed such information to a file system
that may be impacted.

Doug Gilbert


-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html