I run NetBSD 7.0/hpcarm (previously NBSD 6.1.1 through 6.1.5) on a daily-use machine directly from a CF since August 2013. During an upgrade from 6.1.5 to NetBSD 7.0 RC2 a few months ago, I finally ran into a pretty gnarly write error condition on a 4GB SanDisk CF. I bought a fresh 16GB card to replace it, but formatting it seems to have worked (fingers crossed) and it's still working fine in a different machine. CF is pretty robust. I would hesitate to put a swap partition on it, but other than that, I'd think you would be fine, especially with syslog buffering in RAM as Stu mentioned.
Back in 2006, I was running a cluster of 200-300 OpenBSD 4.x 1U rackmounts purely from ramdisk, booting from 64MB Kingston USB sticks. I won't lie. It was kind of a pain in the butt, but things are probably a little better these days. On Thu, Oct 15, 2015 at 1:57 PM, Stuart Henderson <s...@spacehopper.org> wrote: > On 2015-10-15, Stefan Sperling <s...@stsp.name> wrote: > > On Thu, Oct 15, 2015 at 06:19:12PM +0200, Paolo Aglialoro wrote: > >> 2. What is the correct filesystem type to put in fstab for all the > entries > >> of point 1. in order to store them in ramdisk? > > > > I'm using a line such as: > > > > swap /var/log mfs rw,nodev,nosuid,-s40M,-P/var/log.tmpl 0 0 > > > > to put /var/log into RAM. See man mount_mfs for mount options. > > > > The /var/log.tmpl directory is a template which I simply renamed from > > the original /var/log directory. This keeps permissions intact and > > ensures that required files are present. > > > > As an alternative, there's also tmpfs (see man mount_tmpfs). > > The fstab line looks almost the same: > > > > swap /ramdisk tmpfs rw,nodev,nosuid,-s128M 0 0 > > > > > > Or you can use 'syslogd -s' and memory buffer logging (syslogc to view > them). The main reason I'd see for doing this is to reduce the risk of > dirty filesystems getting in the way of a reboot. CFs can handle plenty > of writes - I've personally used CF cards to run systems on for quite > a few years - I've seen a few failures relatively early in their life > (including ones with very writes) but don't remember any failing later > in any way that could be attributed to writes - though I've retired > quite a few due to them being too small after a couple of years of > updates (too much surgery is required to run a recent OS on a 64MB > card ;)
