> choosing that particular eMMC, likely not something specced for very high write endurance, or not speccing a larger amount of flash to spread the write endurance out over a period of up to 20, 25 years.
The problem is that there isn't any wear leveling happening at all, so if you have an event that happens at every boot up and is logged, it wears the same block every time.
> not making that a socketed/removable part.
It's a very integrated module, I don't think socketed ICs have been a thing in automtive for a long time.
edit: I'm wrong, daughter post has a nice run down
If you're curious the very long forum thread is a lovely read.[1] You can see the chip levels itself, because just soldering in a bigger chip with the same code on it makes a big difference to many customers.
> The problem is that there isn't any wear leveling happening at all, so if you have an event that happens at every boot up and is logged, it wears the same block every time.
This isn't true. Very nearly all eMMC devices have hardware wear leveling. They aren't like MTD (raw flash) devices or very cheap USB/SD where you have to rely on a block remapping layer or special filesystem because there is no hardware wear leveling. But like any flash device, when they are completely full there are fewer free blocks for the wear leveling to operate. Tesla also may have had them grossly misconfigured, but I haven't seen any evidence that it was anything other than good-old-fashioned log churn on a very full filesystem. I also understand Google kind of had them over a barrel with policies related to the caching of map data and aerial imagery too: since they could not retain this for very long, caches were constantly invalidated and the same data was being redownloaded over and over. At this point, I don't even think they cache map imagery to storage anymore.
Regardless of the technical details, it's clear that Tesla gave little consideration to this problem during design and did even further damage by wasting their small remaining space by filling it up with Elon's glorious vision of fart sounds, fireplace videos, and games -- Which are great fun, not gonna lie, but in hindsight a terrible decision that greatly exacerbated this problem.
I'm not a professional embedded systems person by any stretch, but I was watching out for this problem even in my hobby projects back in the 90's which used early flash memory products like DiskOnChip modules. To this day, I still buy SSD's that are a minimum of twice as large as I think I will need for every application? For things like all-flash SAN I double it yet again. Anyone who would like to understand why can look at my fat stacks of dead Intel SSDs that all died basically because they filled up. My point is that this sort of thing is really well known and there must have been hundreds of times people within Tesla had questioned this internally.
I didn't mean literally socketed, but in 2012 things like msata interface cards (a predecessor of m.2) absolutely were a thing. Or implemented soldered on a custom small pcb to edge pin interface not very different in size and slot from a laptop sodimm.
The problem is that there isn't any wear leveling happening at all, so if you have an event that happens at every boot up and is logged, it wears the same block every time.
> not making that a socketed/removable part. It's a very integrated module, I don't think socketed ICs have been a thing in automtive for a long time.
edit: I'm wrong, daughter post has a nice run down
If you're curious the very long forum thread is a lovely read.[1] You can see the chip levels itself, because just soldering in a bigger chip with the same code on it makes a big difference to many customers.
https://teslamotorsclub.com/tmc/threads/consolidated-emmc-th...