Hi Jan, Stuart and all that replied off list First of all thanks for confirming which was the directory cache I had a quick scan (not full read through the manual page (mea culpa)
Re wear, (and to some extent ) trying to avoid fsck after an unsheduled power incident. The biggest issue I have seen is where you have a chatty daemon talking to /var/log we find that wears out the flash quite quickly... and the probabilty it will be writing to disk during a power event was approaching 100% so I wanted to reduce the probability of a write to the disk during a power event (as a lot of these devices are in less than ideal locations beside users / customers even :) and without any power backup / conditioning ... as an aside we used to mfs mount /var but this made updates / upgrades a pain... so now we have reduced it to the following mount points /tmp /var/run /var/log and this seems to work well enough for us ... but Criticisims and advice and suggestions welcome ... All the best, and thanks for the help folks Tom Smyth On Thu, 4 Sept 2025 at 15:07, Stuart Henderson <[email protected]> wrote: > On 2025-09-04, Jan Stary <[email protected]> wrote: > > On Sep 04 12:53:05, [email protected] wrote: > > > >> we currently memory mount the following mount points to reduce flash > wear > > > > What flash wear? > > as I'm sure you are aware, flash storage has limited erase cycles > > if the storage is connected via NVME, you may have some insight about this: > > $ sysctl hw.sensors.nvme0 > hw.sensors.nvme0.temp0=41.00 degC, OK > hw.sensors.nvme0.percent0=10.00% (endurance used), OK > hw.sensors.nvme0.percent1=100.00% (available spare), OK > > the type of flash typically used as "SSD" storage has _a lot_ of writes > available, though some others (SD cards etc) often don't do as well > > > -- > Please keep replies on the mailing list. > > -- Kindest regards, Tom Smyth.
