It's an interesting discussion.
The advantage to write it to eMMC is that it will be saved upon reboot. Now, a mechanism to copy it to eMMC upon reboot can accommodate for that unless for those times that the system cannot properly shutdown any more. Or when serious problems are suspected, the tmpfs mechanism disabled.
Luckily the rsyslogd is configured to not fsync() upon every message added to /var/log/syslog (but not for the other logfiles), as the system doesn't perform much other I/O, and /var/log/syslog is flooded with status messages from various Tesla applications, one could assume multiple write flushes per second by the ext3 filesystem.
To make things worse, ext3 has a journal, and it's enabled; you can check with:
tune2fs -l /dev/mmcblk0p3
Journaling on such a small and relatively fast partition does not make a lot of sense anyway.
This means that prior to writing to the eMMC, the kernel will indicate it's going to do so by writing to the on-eMMC journal first, and removing it from the journal afterwards (2 extra write operations).
To worsen things further, the filesystem is mounted with 'barrier=1'. This means each filesystem flush to of log entries to /var/log/syslog will lead to (I quote from the link below):
1.The log blocks are written to the journal.
2. A barrier operation is performed.
3. The commit record is written.
4. Another barrier is executed.
5. Metadata writes begin at some later point.
Barriers and journaling filesystems [LWN.net]
The other filesystem mount option is 'commit=20', which means that the maximum time for a write flush to happen is 20s (where the default is 5s). However, it only has a noticeable effect on read/write intensive systems (which this isn't really). Sadly this does not mean that writes will only happen every 20s, just that you are assured that it will happen within 20s.
When measuring with: iostat /dev/mmcblk0p3 10
one can see that while the car is idling; there are between 0.1 and 1 transactions per second (one can presume about 5 writes every 10s on average) that does not sound that awful. But when tmpfs is used, this is effectively 0. Assuming 24/7 operation for 30 years, this translates to almost a billion erase cycles, more than one could presume 'safe'. I would like to keep our Model X for 20 years...
Much has also to do with the specific quality and specification of the eMMC (amount of erase cycles for each block), less writes on eMMC are always better for the lifespan. If anecdotical evidence supports that eMMC is often corrupted since cars from 2012; I strongly recommend to disable logging to eMMC (and consider disabling the journal with tune2fs).
I'll go for it and implement it in the FreedomEV project (both for IC and CID). I'll call the feature 'StorageKnight'
These are knights who say 'Ni!' to french peasants who sing with a french accent: 'We want to write to eMMC! We want to write to eMMC!' ;-)
And then I need to put it into another movie of course :-D
