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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
