On Wed, Apr 27, 2011 at 3:16 AM, Adrian Hunter <[email protected]> wrote: > On 26/04/11 16:19, Arnd Bergmann wrote: >> >> On Saturday 23 April 2011, John Stultz wrote: >>> >>> From: David Ding<[email protected]> >>> >>> CC: Chris Ball<[email protected]> >>> CC: Arnd Bergmann<[email protected]> >>> CC: Dima Zavin<[email protected]> >>> Signed-off-by: Bentao Zou<[email protected]> >>> Signed-off-by: David Ding<[email protected]> >>> Signed-off-by: San Mehat<[email protected]> >>> Signed-off-by: John Stultz<[email protected]> >> >> The disable_multi logic was introduced in 6a79e391 "mmc_block: ensure >> all sectors that do not have errors are read" by Adrian Hunter. Maybe >> he can comment on this. >> >> My impression is that the code makes more sense without this >> add-on patch, because the flag is set for exactly one request >> and makes mmc_blk_issue_rw_rq issue all blocks in that request >> one by one up to the first error, while after the patch, >> we would read one sector, then read the remaining request at >> once, fail, and read the next sector, and so on. >>
You could definitely interpret the retry path as being: - do a probe sector-sized read/write - if it succeeds, pretend everything is fine and retry with disable_multi=0 - else the probed sector must the point of failure ...it would mean more retrying in the case of an actual card failure mode (at which point you're not doing much anyway), and drastic improvement in the case of some one-time (or not so one-time) host glitches... The other thought I have is that it's not ideal to overcomplicate the logic inside issue_rw_rq (i.e. bisection stuff). Until Per's refactoring as part of async issue it was already too big :-). What do you think? Anyway I hope the patch owner weighs in. A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
