Given the state of modern flash technologies, I think in certain regards you're going beyond practical necessity.
If you use the right CF (or usb) flash technology, the practical lifetimes are easily in the 7 to 10 year ranges. You're looking for the following -- NAND (not NOR) based, single level cell SLC (not multi level cell MLC), with wear leveling engine and, ideally, error correcting engine. A competently implemented "TRUE IDE (ATA)" mode is necessary for uncomplicated BIOS (booting) support. For performance, UDMA support is highly desirable as most retail CF for multi-media uses (e.g. camera and mp3 uses) are slower but broadly compatible PIO mode only. Don't get dazzled with 45X, 133X speed stuff -- inspect for UDMA mode 4 (or better). The premium and can't go wrong (bet the production farm) choice is www.stec-inc.com/flash/. A safe and better price point choice is TRANSCEND INDUSTRIAL CF (www.logicsupply.com/categories/flash_memory). The value choice -- if you do the vetting -- is KINGSTON CF (some of their "lines" are MLC and may not have wear leveling, ecc or UDMA). There may be other choices and sourcing but that's where my journey led me. On competent flash, just do your mounts as rw and use noatime and perhaps async. Use mfs for /var/log and perhaps other high write frequency paths. I use the following. -----snip----- /dev/wd0a / ffs rw,noatime 1 1 /dev/wd0e /tmp ffs rw,nodev,nosuid,noatime 1 2 /dev/wd0d /var ffs rw,nodev,nosuid,noatime 1 2 swap /tmp mfs rw,-s=65536,nodev,noexec,nosuid 0 0 swap /var/run mfs rw,-s=4096,nodev,noexec,nosuid 0 0 swap /var/log mfs rw,-P=/etc/proto/var/log,-s=16383,nodev,noexec,nosuid 0 0 swap /var/tmp mfs rw,-s=16384,nodev,noexec,nosuid 0 0 -----snip----- I use KINGSTON (good) and TRANSCEND CF (better) and just installed openBSD straight from install42.iso (and more recently 4.3-RC), with no other special considerations. -----Original Message----- From: SchC6berle DC!niel <[EMAIL PROTECTED]> To: misc@openbsd.org <misc@openbsd.org> Subject: Re: soekris/pcenginges and RO mounting Date: Tue, 25 Mar 2008 17:48:37 +0100 Delivered-To: [EMAIL PROTECTED] Just a couple of nitpicks: - I don't think you gain anything with noatime and async on a mfs (useless) - /etc/rc mounts / rw, it's not enough to specify ro in /etc/fstab. You have to either: a) modify /etc/rc, or b) remount / ro in rc.local - no need for a "fake" /var, just use the real /var for mfs - it's useful to have a rw /home - it's the only rw thing on my CF Regards, Daniel. > From: Lars Noodin [mailto:[EMAIL PROTECTED] > Martin Marcher wrote: > >... > > What I'm looking for are starting points to read about what > to do when > > RO mounting the root fs (and all other parts) especially on > CF-media. > > I did this recently, in December and January, and can point out what I > found. More experienced or expert users will be able to say what the > better options are. > > Since the smallest CF I could get was 1GB, I split it into > two, to have > one for the root tree and another partition for reserve copies in case > experiments don't work. The whole system, including extras, is about > 202 MB. I chose to do any compilation on another machine and > therefore > left out comp, the man pages (for me) are as essential as the > kernel so > I've kept them. I can't remember why I kept misc. > > [X] bsd > [X] bsd.rd > [ ] bsd.mp > [X] base42.tgz > [X] etc42.tgz > [X] misc42.tgz > [ ] comp42.tgz > [X] man42.tgz > [ ] game42.tgz > [ ] xbase42.tgz > [ ] xetc42.tgz > [ ] xshare42.tgz > [ ] xfont42.tgz > [ ] xserv42.tgz > > I chose to have /tmp, /var, and /dev in memory and put the rest of the > normal system into one partition. /home is a symlink to /var/home/, > /root is a symlink to /var/root, /data is a separate > partition for spare > material and short term backup. No swap partition was used. > > Templates for /dev and /var are kept in /dev.base and /var.base, > respectively. There are probably better naming conventions. > mfs loads into RAM and then mounts the RAM versions. > > Here is what I have in /etc/fstab (wrapped text) to do that: > > /dev/wd0a / ffs ro 1 1 > /dev/wd0d /data ffs rw,nodev,nosuid 1 2 > > # populate /var with data from CF, then mount in RAM > swap /var mfs -P/var.base,-s160000,noexec,async,nosuid, \ > nodev,noatime,rw 0 0 > > # mount /tmp in memory > swap /tmp mfs noexec,async,nosuid,nodev,noatime,rw, \ > -b4096,-i1024,-s15000,-m0 0 0 > > # mount /dev in memory > swap /dev mfs rw,-P=/dev.base,-s=3000,-i=1024 0 0 > > When you make changes, mount -o rw /, then make the changes then sync. > > I have also used config(8) to tune the GENERIC kernel somewhat. Just > what I chose, I cannot recall, but when it is time to look at that > again, I will try removing unneeded devices. > > Here is what I chose to have in /etc/boot.conf, the > re-configured kernel > is called /nbsd: > > stty com0 19200 > set tty com0 > #set image /bsd > set image /nbsd > > To use cu, kermit or tip for serial console, you must be a > member of the > group dialer. > > I'm going to assume you have already set up a way to do the > installation. I chose to use PXE boot. Now that I seem to > be swimming > in USB devices and media, I will probably try using those next time > instead. Having PXE boot available is an advantage later if > you want to > set run live CDs or thin clients. > > For the logging, I've chosen not to worry about it yet. When the > machine powers down, the logs are lost. Maybe you could set up > something in /etc/rc.shutdown to rsync to a non-volatile partition. > An external log server is another option. I've had log servers in the > past, but will postpone that till I can experiment more with IPv6. > There was a good IPv4 summary of logging on BSDTalk in January: > > http://bsdtalk.blogspot.com/2008/01/bsdtalk138-central-syslog.html > http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk138.ogg > > There is apparently a risk that the log partition on the log > server can > get filled by anyone who wants to do so. > > YMMV, > -Lars
