Doing the research reveals the true case about wear on flash memory style devices and that is that substantially reads do *not* damage the cells at all, at least no more than reading, say, DRAM. It is block erases and writes that do and so, paradoxically, when used as a PROM, probably wear levelling is entirely unnecessary. And if done gratuitously may actually reduce lifetime. By 'gratuitously;, I mean that it is done when there is no write operation in progress. I cannot see any reason why one would shuffle blocks around *except* as a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb the data (read distrurbance), and that is that read operations can minutely affect the state of physically adjacent but unread cells. However this is generally at least an order of magnitude below write damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static configuration files will exceed 32 million per annum, or rather they would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that is fully cached (my files are less than 1kBytes) as valid. I cannot see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to the SD card *at all*.
And in fact in my particular application one code and data is loaded, even changing the configurations files should not result in a physical read, as the disk cache itself used to do the writing will retain the information.
I think the summary of all of this research is significant for PI users running Linux in what may be generally classed as 'read often, write seldom' accesses to an SD card, and that is that by far and away the greatest protection the card has is the Linux disk buffering algorithm itself, provided that constant reads do not exceed its capacity. In a typical 24x7 applications there is no reason why, post boot, any SD reads should happen *at all*, once the disk cache is full. It also shows the absolutely vital role that '-noatime' plays in protecting read only files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation eventually between writes to the linux file system and writes to the SD card: The exception being data that us rewritten to the same disk file cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective manner, is to reduce writes to a minimum by firstly mounting the card
-noatime, and secondly using RAM disks to do any logging that you can't turn off, and for all operations where ephemeral data are being recorded and read, but which do not need to survive a reboot. Then, having a superfluity of RAM available for disk caching will reduce SD *reads* to essentially zero. No matter how often the file system is accessed by the application.
And in fact using iostat on my running application shows no (physical) reads or writes *AT ALL*. As evinced by the rock steady light on the Pi Zero.