I doubt that this issue is your problem. But in response to one remark: > On the theory that these writes may > be stalling due to the block number, (and we haven't seen any evidence > yet of this), you can test for that by repeating the writes...
There *is* evidence that accesses to some block numbers in MLC flash chips are much faster or slower than others (like 5x slower). They seem to be designed with "fast blocks" and "slow blocks", though this is undocumented. There is no interface for telling the software which is which (except by actual measurement of the responsiveness of the chip -- and in microSD cards, accesses are mediated by a Flash Translation Layer of unknown characteristics). See: Characterizing Flash Memory: Anomalies, Observations, and Applications Laura Grupp, Adrian Caulfield, Joel Coburn, Steven Swanson, Eitan Yaakobi and Paul Siegel UCSD Tech Report CS2009-0946 August 19, 2009 Unfortunately the amazing people at UCSD fail to put up their archival tech reports in readily accessible PDFs. (It seems to be some sort of half-assed DRM system, since they yammer about copyrights on the same page.) They do have a mangled (OCR'd!) abstract here: http://csetechrep.ucsd.edu/Dienst/UI/2.0/Describe/ncstrl.ucsd_cse/CS2009-0946 and a mangled 18MB PostScript version available here: http://csetechrep.ucsd.edu/Dienst/Repository/2.0/Body/ncstrl.ucsd_cse/CS2009-0946/postscript The Wayback Machine failed to capture it while it was there. But I got the PDF from them when they had published it in 2009. I have put up the 1.5MB PDF temporarily here "for research purposes": http://www.toad.com/TEMP-Grupp-2009-TR-FTest.pdf with the slides here: http://www.toad.com/TEMP-Grupp-2009-FMS-FTest.pdf John _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
