I have tried this, which seems reasonable to me:

# cat /etc/fstab
# Device        Mountpoint    FStype    Options        Dump    Pass#
/dev/ad1s1a        /        ufs    rw,noatime,sync        1    1
/dev/ad1s1b        none        swap    sw        0    0
/dev/ad1s1d        /var        ufs    rw,noatime,noasync        2    2
/dev/ad1s1e        /tmp        ufs    rw,noatime,noasync        2    2
/dev/ad1s1f        /usr        ufs    rw,noatime,sync        2    2

However, after reboot I get

# mount
/dev/ad1s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad1s1d on /var (ufs, local, noatime, soft-updates)
/dev/ad1s1e on /tmp (ufs, local, noatime, soft-updates)
/dev/ad1s1f on /usr (ufs, local, noatime, synchronous, soft-updates)
devfs on /var/dhcpd/dev (devfs, local)

So, it would seem that pfSense is overriding my definitions for the root file system.

Afterwards:

# mount -a
# cat /etc/fstab
# Device        Mountpoint    FStype    Options        Dump    Pass#
/dev/ad1s1a        /        ufs    rw,noatime,sync        1    1
/dev/ad1s1b        none        swap    sw        0    0
/dev/ad1s1d        /var        ufs    rw,noatime,noasync        2    2
/dev/ad1s1e        /tmp        ufs    rw,noatime,noasync        2    2
/dev/ad1s1f        /usr        ufs    rw,noatime,sync        2    2

shows that FreeBSD knows what I meant !!

First of all, I can confirm that noatime helps to prevent corruption of filesystems.
Further, sync on / and /usr on a custom install helps to further prevent corruption of filesystems.

However, there is another problem in /etc/rc line 70.
After having done a mount -a the above line states

/sbin/mount -uw / || (/sbin/fsck -fy; /sbin/mount -uw /)

I would suggest to change this to:

--- rc.ORIG    2010-03-27 16:02:53.000000000 +0100
+++ rc    2010-03-27 17:07:06.000000000 +0100
@@ -66,7 +66,7 @@

 # Mount /. If it fails run a fsck.
 if [ ! "$PLATFORM" = "cdrom" ] ; then
-    /sbin/mount -uw / || (/sbin/fsck -fy; /sbin/mount -uw /)
+    /sbin/mount -a || (/sbin/fsck -fy; /sbin/mount -a)

     # If /conf is a directory, convert it to a symlink
     # to /cf/conf

In my configuration, the above has survived 10 power-yanks (where the vanilla pfSense installation never survives power-yank in my configuration).

My conclusion¶

1) Make all filesystems noatime in /etc/fstab
2) Make the / root filesystem sync in /etc/fstab
3) Apply the above patch to /etc/rc

Any news or comments on this issue?

This all looks sane but have you tested these changes on all of the distributions (livecd, nanobsd, etc)?

Also, why do you use separate usr, var, and tmp?? That is not what the installer defaults to and is widely tested to be OK.

I have only tested on full install from live CD.
It is quite difficult for me to try nano, as I have to dismantle the box and move the disk to a PC to reinstall, and I do not have CF so I can not test that.
I was hoping that maybe someone else with those distributions could test on them...

As mentioned on the forum thread referenced in the bug description, I tried some 10 or 20 times to yank power on a default install (just one partition), and it never came up OK. I have done many FreeBSD installs (but this is my first pfSense experience), and usually FreeBSD comes up after yanking power, if correctly partitioned and configured. So that's why I changed to multiple partitions and modified fstab settings. (Also I would like to have squid, snort, and heavy tcpdump'ing on the box, in which case I think a partitioned environment is more appropriate).

If you have access to VMware Workstation, you can make a NanoBSD VM to test in. The serial port can be virtualized by use of named pipes, which can be connected to from PuTTY.

I'm not sure if there is a way to make a similar trick work from Virtualbox or other VM systems.

Unfortunately I don't have VMware, and my only KVM capable PC is out of service.
In any case I am not so sure that using a VM is a suitable approach for testing power yank. Of course the VM can be killed, but I doubt that the results would be similar to yanking power on real hardware.

In this case the power yank isn't what really needs testing, it's whether or not the mount commands and changes would have the desired effect in those scenarios.

The issue Henrik was seeing was just from having multiple partitions and them not getting fscked properly at boot time prior to Scott's commit today. Almost no one runs that way, though it is desirable in some circumstances, and some hardware won't boot without a smaller /. I can confirm with multiple mount points if you pull the power, it will never boot properly (without going into single user and running fsck manually) prior to today.

FWIW, for the sake of the testing in this thread, powering off a VM is exactly like pulling the power plug out of physical hardware. It shuts down the machine with a dirty disk.

Setting back to New to take care of the two remaining things noted in this thread.
1) noatime
2) sync

Tested the suggestion in the second comment on nanobsd 2.0 b4 and I got override questions on /conf, what I did to force a secondary CF to be mounted is adding '/sbin/mount -a' near the end of /etc/rc

At this point I am not to keen on touching the BSDInstaller. We should set this ticket to future and deal with this with our new installer infrastructure.