Tue, 21 Jun 2016 09:55:47 -0400 Kenneth Gober <kgo...@gmail.com> > On Sun, Jun 19, 2016 at 5:56 AM, Sjöholm Per-Olov <p...@incedo.org> wrote: > > Does anyone know if there exist any list of recommendations about how to > make > > an SSD disk to live as long as possible when using it for firewall purpose > on > > OpenBSD? > > I don't know of a list, aside from what you find in this thread and similar > threads on this list from the past. > > My own first recommendation is not to worry about it. > > My second recommendation is: if you must worry about it, change as little > as possible. you don't want to make updates difficult due to excessive > customization. > > I am running OpenBSD 5.9 on an Internet-facing router, on Soekris hardware > with > 4GB mSATA SSD storage. My only concern about SSD durability relates to > /var/log and the potential for Internet traffic to cause constant writes > there. > So I have made minimal changes to guard against that: > > DO NOT MAKE THESE CHANGES ON YOUR OWN SYSTEM UNLESS > YOU UNDERSTAND WHAT THEY DO. > > 1. when installing OpenBSD, put /var/log on its own 128MB partition. > > 2. after your first boot, convert /var/log to use MFS: > mkdir -p /mfs/log > cd /etc > mv fstab fstab~ > sed -e's|/var/log|/mfs/log|' <fstab~ >fstab > cat >>fstab > swap /var/log mfs rw,nodev,nosuid,-s=128M,-P=/mfs/log 0 0 > ^D > > 3. reboot so that the above /etc/fstab changes take effect. > > 4. configure rsync to periodically checkpoint /var/log to /mfs/log: > pkg_add rsync > crontab -e > (add the following lines) > # > # checkpoint log files > 10 */4 * * * /usr/local/bin/rsync -ayH > --delete-after /var/log/ /mfs/log > > 5. also save /var/log to /mfs/log on shutdown: > cat >>/etc/rc.shutdown > /usr/local/bin/rsync -ayH --delete-after /var/log/ /mfs/log > ^D > > I sync /var/log to /mfs/log only every 4 hours because I have reliable power. > If you have unreliable power (or unreliable hardware) or your firewall > crashes > or reboots for unknown reasons you may want to sync more often. Actually > in that case you probably shouldn't use an MFS /var/log at all. > > When I first did this it was more than 2 years ago. Today SSD storage has > improved enough that this shouldn't be needed (see my first recommendation > above not to worry about it). > > -ken
I like this approach, however in my independent thinking, writing to a memory file system happens.. too fast (and is trouble working around). You would wonder how this may be a bad thing, i.e. this is the idea to be fast right? And I'll propose a simple example. Suppose there is a bug or unexpected behaviour in some software spilling fast writes to a log file. This does not pass through system log, just plain writes to a file in log directory you put in memory file system. It these were real writes to a disk based file system, no matter cached, buffered etc or not.. it would be much slower than writes to memory. They would eventually dump caches and buffers to real storage medium which is slower and gives you signals (light, sound depending on your enclosure) and moreover.. enough time. It is not very difficult to figure you would sometimes want some logs for your review, and even depend on log availability on the system.. Yet you found yourself in that situation late, they are blocked because some file grew very rapidly to fill up the memory file system and the other logs are not there. This is just one very minor potential downside to memory based file systems, but worth adding as a disclaimer. So, have it in mind, and weigh it against the effort to custom tweak the system on each upgrade. To match the frequency of the upgrades you go through. On my systems that run 24/7 this is weekly, on the systems I use direct it is daily. I can't imagine working around custom stuff daily, it is out on design stage. I'm still backing up the statement that current SSD, like the one queried are not a concern for longevity based on writes in normal usage including log writes, the device controller takes care of this very well. No concern at all. Including on temperature design, they fit in the convection of the entire system. Just have at least 1 fan blow out heat off the system, or put it in a rack with fans or a cool location. What is more important, fast writes to logs, log availability, or your time setting up and working around custom designs? Just another view.
