On Tuesday 09 September 2014 10:54:51 Johan Rudholm wrote: > 2014-09-03 16:24 GMT+02:00 Johan Rudholm <jrudholm@xxxxxxxxx>: > > Hi all, > > > > as you know, NAND flash can be programmed a limited number of times > > before it reaches end of life, the number of times varies with the > > NAND technology used, among other things. > > > > As far as I can tell from the simplified SD-spec, there is no way of > > asking the card about how many program/erase cycles it can handle, or > > how many p/e cycles are left before reaching EOL. Right? I think that is correct. > > So, if one should want to give the user some kind of early warning > > that it's time to change SD-cards, is there a way? Also, when a card > > has reached EOL, is there a way of telling this condition apart from > > all other error conditions that may arise? As you know, depending on > > the quality of the card and controller, read timeouts, write timeouts, > > lockups etc may occur but can usually be fixed with a power cycle. > > > > I'm thinking of collecting simple statistics from for instance > > card/block.c and exposing it via an ioctl or sysfs. The statistics can > > be gathered and processed by some user space process which can > > determine if the user needs to be alerted. The statistics can be, for > > instance: > > > > * Writes/reads that timeout, but succeed after a retry > > * Writes/reads that timeout and never succeeds > > * Different kinds of errors in the card status > > * Anything else? > > > > Perhaps it's not possible to detect worn out cards this way, but at > > least it could point out and warn about crappy cards? > > > > Any thoughts about this? Have you tried if this works? In my experience, the worn-out cards I have either just fail completely, or they return incorrect data, but I have not looked at this side of the problem much. Do you have cards that sometimes time out but always still return correct data on retry? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
