Date: Sat, 21 Jan 2017 17:40:10 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: how to measure microsd wear Message-ID: <7bb4a12d-9b5a-2a81-1ce4-5290e2639a9b@denninger.net> In-Reply-To: <1485025911.34897.199.camel@freebsd.org> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms000109000402020503060009 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/21/2017 13:11, Ian Lepore wrote: > On Sat, 2017-01-21 at 12:12 -0600, Karl Denninger wrote: >> On 1/21/2017 11:58, Ian Lepore wrote: >>> On Sat, 2017-01-21 at 15:46 +0000, tech-lists wrote: >>>> Hello list, >>>> >>>> How would one measure microsd wear? Is there a utility like >>>> smartmontools (I think this only works for regular hard drives) >>>> but >>>> for >>>> microsd? >>>> >>>> many thanks, >>> There is basically no way to see what's going on in the flash array >>> of >>> an sdcard. The microcontrollers in modern sd cards have complex >>> wear- >>> leveling algorithms which are completely transparent to the outside >>> world. >> This is true. >>> On the plus side, most of what you see in the way of warnings and >>> scare >>> stories about wearing out sd cards is pure BS. I've got systems >>> here >>> that have been running for literally years on the same sdcard, and >>> that >>> card is being used for swap, and routine data storage like syslog >>> (on >>> an embedded system that logs status and progress pretty much >>> continuously 24x7 for years). I've seen a few sd cards die over >>> the >>> years, but I've never been able to say it was because of how much >>> was >>> written to them (indeed, the dead ones I've got weren't in service >>> long >>> before they died). >>> >> This, however, is total nonsense. >> > Well, no, it's not total nonsense, it's my 10 years of experience > professionally working with sd cards in embedded systems sold as > commericial products, including extensive testing of the card trying to= > *induce* failure. > > Next time think twice before implying I'm either a fool or a liar. I didn't say you're a fool or a liar, I said you're *wrong* with the statement that SD cards don't fail in this application -- specifically microSD cards on embedded machines such as the RPI series running FreeBSD, along with the implication was that the only failures you will see are infant-mortality related. In fact I just had a failure *today* on a production RPI2. While trying to re-copy the filesystem back to it (after it failed, plugged into a different box to check it out) I got the usual behavior: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 1c 4f 40 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command The writing process is frozen because the card has write-locked itself.=20 I confirmed this by attempting to fsck the card after detaching and reattaching it, and as soon as fsck attempted to write to it another error was taken; it's effectively write-locked. I can mount it read-only and read it, but cannot write to it. Another one goes into the bin, and a new card comes out to be set up with said filesystem. In fact I'm doing that right now while typing this= =2E This card was roughly a year old in production use, and gets a fair bit of write activity -- but not a crazy amount by any means. Your mileage may vary, but this is what I've repeatedly seen in behavior by these cards when they go bad -- 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 24x7x365 uptime on it.=20 Sandisk will replace them on request but they most-definitely do occasionally fail. I've started using Samsung EVO cards and I've yet to have any of those crap out, but none of them have more than six months of uptime on them at this point and the failures are rare enough that until I get a couple of years on the EVOs without a failure I can't reasonably say they're superior in this regard. This is the first one that I've had happen in this particular use case and I was surprised by it because of what that machine does. The other two were both much more write-heavy applications, one of them a development unit on my desk that gets a lot of compile activity on it. > I'm not even going to read the rest of the crap you wrote, since it's > completely invalidated by the stupid thing you said above. > > -- Ian > > >> I've had multiple SD card failures in build/test/high-volume write >> environments on the PI2 series over the last year and change. There >> are >> two general ways in which you will see failures: >> >> 1. The card write-locks itself. This is a defensive move by the >> controller when it determines that it cannot reallocate a failed >> block >> during a write (e.g. it's out of spares) OR it takes an unrecoverable >> read error. >> >> 2. The card loses its allocation map (in which case you're completely >> screwed; it will show up as zero size if you manage to get it mounted >> somewhere.) >> >> If you get a type 1 failure you can copy everything on the card off; >> provided you do not attempt to write it, you will not get >> errors. Prior >> to a fairly recent MFC if you had soft-updates on and took a Type 1 >> failure you'd get an instant panic; this has been (I believe >> entirely) >> fixed. >> >> In the event you get a Type 2 failure there's nothing you can do. In >> both cases the card is junk if it happens. >> >> --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000109000402020503060009 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjEyMzQwMTBaME8GCSqGSIb3DQEJBDFCBEBgjR8D qgTiqGdOg5XNSHx6QULjeGND3us/PRZfArL4BWWeFUDIC2MEv8aYRPGOcqSnT5oEBD3U2JQd XojdFyLCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAOzSLzXRL5pKw FUwLZ5zklLFGWWHvsUADeqcFHt+skzSRyv/iy+mF8bm9Gr7OfruUmPvM3upux+hasM4d3Bie LEwMhC+iTj0DS9yBBZVJcvgJ+YCGv2ROoUoJBgXisGZxEjph0sMXuoa8sXkIFPZMv1dEeoxW DbouW3UOZ3iEhDbmVXtxp+WwSAWnDBvgNEqH88Ozmim7JxtgsmEq5P4QlsBEq6VyGO1PSGDI ejmgMkcuIfHOiqzx8QyFO90en98fa8DdQFmeTfHxFFF6gPlq7htMUX0vKGVScSSyt4mupuk7 3yXO/0PliEawsnGGDENDwjlEO+C3TZUZfSIMQlmAwNcsky3ndxGA0nFPtJMa2V/vwBODbQdT c7A+ONQ/WrjcfTYkMluOPl2RJmksFqo0zfRRsbMyBN2Nr5jz5iy47C6n4U/ewvOAnmsHV/18 ot5VlEIRqkpYCR6v9NQ40BcKqzR3mKW/uRDOBpijVioJ0qhDapLfwRbtIOZn9t8YPHAp/LKN ypz/TBQ6kYCIBGjxENzxJ6c7wWbNfn/+BnlMPfnbcnR1O4PCwkVdSav34ltIOc7l2LOAFJpH AeJPn5+psyoEN5et6wSjNiR0vZqihmUBW3aWF9PAIZarTKY+sP3Plf3vWLWqnuMpfOiJUKVs W0czvfhn5r4ShU9FTuiNmVEAAAAAAAA= --------------ms000109000402020503060009--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7bb4a12d-9b5a-2a81-1ce4-5290e2639a9b>