As well represented on the web, excessive writes to the SD card will shorten its life. I am creating an embedded application using the Raspberry Pi, and I definitely don't want a continuous stream of users complaining of dead units due to SD write failures. I believe I have undertaken the majority of measures to mitigate the issue, such as changing the log directories to tmpfs, etc. The next big data writer on the list is chromium-browser. The application is web based, so chromium is up 100% of the time, and it is doing lots of writes. Is there any way to limit or better yet eliminate writes from chromium? A native chromium solution would be great, although I could employ something like tmpfs and write to the volatile area(s) prior to invoking chromium. The main issue there is chromium uses nearly 100M of space for its files. Before embarking one something like this, I would want to trim the files as much as possible, and even then it would be much better if chromium didn't write to disk very much.

Yes, but size and cost are the issues, plus even an SSD suffers from a limited number of writes, although much less so than an SD. There is only about 32mm of clearance between the USB ports and the side wall of the device. If someone makes an economical SSD that only sticks out about 32mm or so (like the tiny thumb drives), I would certainly consider it. I suppose I could also use a thumb drive and mount it to /home/pi/.config. That would eliminate the vast majority of writes (from chromium and LXDE) to the SD card. I don't think thumb drives are any more write-resilient than SD cards, are they? In fact, aren't they internally identical?

Power is not a significant issue, in terms of the current draw of an SSD, and the USB ports are unused.

With Chromium sometimes I just create a zlog and run `chromium-browser --user-data-dir=/var/log/chromium` just to save having a 2nd zdir
As it logs to that dir also if ` --enable-logging --v=1` is enabled

The default with zram-conf creates a demo zdir of the complete /home/pi dir.

If you are going to enable `zram-config enable-ephemeral` make sure any settings or changes are done before reboot as it is ephemeral on each boot `sudo zram-config disable-ephemeral` and reboot will get you back to normal.

If you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.

If you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.

The overlayfs method also allows one to track down which programs tend to slowly flood memory with logs (like systemd, apt status checks, and so on....). I noted widely timed small writes to the same inode can eat through your flash write limit quite quickly. We also looked at a hierarchical priority zram system using several allocations, and found it tended to be less stable over several days. Stretch probably has updated these packages if others are getting more reliable performance, and it may be worth another look.

In terms of the browser.... i seem to recall it has a read-only kiosk mode in addition to "--disable-sync-preferences"... you may want to limit the web file-cache size to under 300MB, system kernel io cache allocation to 2/3 of free ram, and set the system flush-to-disk priority as low as possible. This generally defers disk or swap writes, but also allows the io cache to swell into ram (or zram with a swap priority flag.) I would recommend looking at our kernel settings and config if you want to tweak your own read-only /home mount setup: https://sourceforge.net/projects/microm ... pberry-pi/

As HawaiianPi already stated, a purely ram disk approach is also possible. I am not sure how well Alpine is supported on the Pi, but it is also a minimalist system popular in several container recipes: https://www.alpinelinux.org/downloads/

At minimum, a SLC flash sdcard from digikey will extend your service life around 3-10 times longer than what MLC/TLC based cards offer. "High endurance" cards also tend to burn though their spare replacement sectors with the partial <512 byte small re-writes log files tend to make to the disk area. Normally the sync-to-disk defaults to 5 seconds, so some apps with sparsely-timed numerous smaller writes can sometimes wear the flash faster than expected.

Obviously, I need to dig more deeply into zram, however first I need to find out how chromium's footprint can be reduced. I have already made some inroads into the issue, reducing the footprint by over 17M through eliminating unnecessary files, such as the site blacklist (SafeBrowsing). Another 16M is created every time chromium runs in the two Broswer Metrics files, although I take it zram will compress these writes? They do compress quite nicely. Compressing with the default gz compression yields an image of only 75K. Most of the remaining 35M or so is in ~Default/Local Extension Settings (17M) and ~Default/Extensions (11M). How much of this can be blown away?

The OS is not the problem. Other than LXDE, I have pretty much eliminated all writes to the drive by the OS by mounting /var/log, /tmp, and /var/tmp on tmpfs. LXDE does some writes that I think I can pretty much eliminate. The big offender is chromium-browser, which not only writes a lot, but has a lot of large configuration files.

If you are going to enable `zram-config enable-ephemeral` make sure any settings or changes are done before reboot as it is ephemeral on each boot `sudo zram-config disable-ephemeral` and reboot will get you back to normal.

If you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.

I follow some, but definitely not all of that. Again, I will delve more deeply when I have had some sleep. One important thing of which I am not sure:

I want to be able to perform upgrades on the fly by updating certain files on the drive. Obviously, these changes cannot be volatile. Is there a way to make some changes permanent?

If you are going to enable `zram-config enable-ephemeral` make sure any settings or changes are done before reboot as it is ephemeral on each boot `sudo zram-config disable-ephemeral` and reboot will get you back to normal.

If you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.

I follow some, but definitely not all of that. Again, I will delve more deeply when I have had some sleep. One important thing of which I am not sure:

I want to be able to perform upgrades on the fly by updating certain files on the drive. Obviously, these changes cannot be volatile. Is there a way to make some changes permanent?

Problem is with the whole root ro that you need to umount the overlayfs as any further writes could be problematic as the merge down will break the logic between upper working directories and lower that result in the mount.
You prob could do it on a shutdown as the further writes are in volatile and its going to shutdown, but not sure of effect if any.
With the individual directories set in ztab they can be unmounted and merged on shutdown and all changes are merged down with no vagaries of effect.
OverlayFS took over Aufs as Aufs does have some performance problems, but think there is some kernel politics at play which is a shame as AuFs does have a range of utils that is totally lacking with OverlayFs.
Prob is the majority of distro's don't have the the Aufs kernel modules enabled or even included and OverlayFS is great but the lack of utils apart from the singular merge tool I use is not.
I am pretty sure an online (mounted) merge is more than possible but far beyond my ability or overall knowledge of the nuts and bolts of overlay FS but the mechanism of overlayfs is actually quite simple, deliberately by design and maybe why its been left light of accompanying utils and methods.

I still need to do some investigation into zram, but in the meantime, I have reduced the writes to the SD card tremendously. There are a few things that remain the highest write rate on the card:

1. Directory updates. In particular, even though the sub-directories are tmpfs mounts, the listing of several of the directories in the root are being updated because their contents are being updated. In particular, /run, /sys, and /tmp get updated a lot. I'm not sure how to prevent this while still allowing writes to the directory pointers (i.e. file create, file delete, and file move operations).

2. The file /var/lib/systemd/clock gets updated whenever the systemd-timesync daemon synchronizes the time. Is there some way to either stop this or else to have the daemon write to some other directory?

tmpfs = ram just not compressed purely volatile memory not affected by power loss as not persistant.

Clock yeah do as I say just create a zram directory and either move the conf setting to point there or create the dir there.
I should really update zram-conf as thinking about it the lower RO directories could be an array or dorectories.

using f2fs for the partition where chromium writes
mounting the partition with commit=x argument (x is the number of seconds the cache has to be flushed after, look for documentation for full explanation)
mount the partition with noatime argument, so there is the access time is not changed every time a file is accessed