Date: Sat, 21 Jan 2017 22:29:32 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: how to measure microsd wear Message-ID: <eef976be-7261-14cb-153b-9eb7a4bdd43b@denninger.net> In-Reply-To: <20170122002432.B16E8406061@ip-64-139-1-69.sjc.megapath.net> References: <20170122002432.B16E8406061@ip-64-139-1-69.sjc.megapath.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms070404060709020904080902 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/21/2017 18:24, Hal Murray wrote: > karl@denninger.net said: >> and this one is not a low-hour failure either, nor is it an off-brand = -- >> it's a Sandisk Ultra 32Gb and the machine has roughly a year of 24x7x3= 65 >> uptime on it. > Any idea how many writes it did? Offhand, no. I did not expect this particular device to have a problem given its workload, but it did. It could have been a completely random even (e.g. cosmic ray hits the "wrong" place in the controller's mapping tables, damages the data in it a critical way, and the controller throws up its hands and says "screw you, it's over.") There's no real way to know - the card is effectively junk as the controller has write-locked it, so all I can do (and did) is get the config files and application it runs under the OS off it and put them on the new one. The other failures were less-surprising; in particular the box on my desk, given that I compile on it frequently and that produces a lot of small write I/O activity, didn't shock me all that much when it failed. One of the big problems with NAND flash (in any form) is that it can only be written to "zeros." That is, a blank page is all "1s" at a bit level, and a write actually just writes the zeros. This leads to what is called "write amplification" because changing one byte in a page requires reading the page in and writing an entire new page out, then (usually later) erasing the former page; you cannot update in-place. If a page is 4k in size then writing a single byte results in an actual write of 4k bytes, or ~4,000 times as much as you think you wrote. This is also one of the reasons that random small-block write performance is much slower than big writes; if you write an even multiple of an on-card block the controller can simply lay down the new data onto pre-erased space, where if you write small pieces of data it cannot do that and winds up doing a lot of read/write cycling. It gets worse (by a lot) if there's file metadata to update with each write as well because that metadata almost-certainly winds up carrying a (large) amount of write amplification irrespective of the file data itself. All of this is a big part of why write I/O performance to these cards for actual filesystem use is stinky in the general case compared against pretty-much anything else. The controller's internal logic has much voodoo in it from a user's perspective; the manufacturers consider exactly how they do what they do to be proprietary and simply present to you an opaque block-level interface. There are rumors that some controllers "know" about certain filesystems (specifically exFAT) and are optimized for it, which implies they may behave less-well if you're using something else. How true this actually might be is unknown but a couple of years ago I had a card that appeared dead -- until it was reformatted with exFAT, at which point it started working again. I didn't trust it, needless to say. SSDs typically have a published endurance rating and a reasonable interface to get a handle on how much "wear" they have experienced.=20 I've never seen either in any meaningful form for SD cards of any sort.=20 In addition SSDs can (and do) "cheat" in that they all have RAM in them and thus can collate writes together before physically committing them in some instances, plus they typically will report that a write is "complete" when it is in RAM (and not actually in NAND!) Needless to say if there's no proper power protection sufficient to flush that RAM if the power fails unexpectedly very bad things will happen to your data, and very few SSDs have said proper power protection (Intel 7xx and 3xxx series are two that are known to do this correctly; I have a bunch of the 7xx series drives in service and have never had a problem with any of them even under intentional cord-yank scenarios intended to test their power-loss protection.) I'm unaware of SD cards that do any of this and I suspect their small size precludes it, never mind that they were not designed for a workload where this would be terribly useful.=20 The use envisioned for most SD cards, and their intent when designed, is the sequential writing of anywhere from large to huge files (video or still pictures) and the later sequential reading back of same, all under some form of a FAT filesystem (exFAT for the larger cards now available.)= IMHO the best you can do with these cards in this application is to minimize writes to the extent you can, especially small and frequent writes of little actual value (e.g. mount with noatime!) and make sure you can reasonably recover from failures in a rational fashion. --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070404060709020904080902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjIwNDI5MzJaME8GCSqGSIb3DQEJBDFCBEDwYObI PCJD4wSASsw+8EO0w4ZGdFmPuJDKzUXCBSxOJ/8aQvvY1NHl2XW0tDiEMcCBSaAhI7Li77KB MQj5RTD0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAgUo8F8FLpAWb EOFgiH3tCI5skGzmZNqPYaTO5T6hJ1xDKkzeR0P5krDtjR7zX8Bc1Pa6wvTZ5zHd39gWLkcG QZ3sj49hLGdt5pSO7s+Rf9AMcqY4x3DB85JBMQ2DC7gC5FjBCZOGx1OtNB+hnucd9zd8X4qO 3Dnoez8ZV0dSMzEV2kQMEaB3ctSR6Q1SRTWbhXi/ffV2BN7uLr6OJDOfCF8N2AfKYWiUxddI RiOYZGcuHZ3kKdNHq2HoHs0qSTkDCzB4ynnLSi1+sFtYlgCSzRQaT6SXV87ff5yVXCgzJ4yl 885u6PyCP8k1yXKy6zzjYuDsEF7d5x/JvtzYOMs8EKCqhYTl97ICdem2mmJkqKqMEwLJCPeo yde1jmvQrNA/+6G3zrYUiZdEMHTNtRzXD3rRSMLiaVbdVcyXZVVqLAa+YZl/vVXNqhUWeLEV LX7ncr8RaMHIysIcSMKeDvWhxtHwW+DnU2beJEou4DTIOc9gG0R9QlpW2wms6XszesGNAfcM t6B2zXQQ2WNfJ0Zf6Tx8qBZ6tQ0p+0JnT8YHdPeJBzrKpKzhcJOoWrJwnYpvX5rNeu6gjOUz PFP/hVIl4zs4kheQChHXpnUAxVujl+sjg3MwOlWkcMQRYpxQnm+zIX4HdJNrIcGUitiPKhKu FqeE/DBbs+PZcqY/q6dlRWwAAAAAAAA= --------------ms070404060709020904080902--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eef976be-7261-14cb-153b-9eb7a4bdd43b>