Am 03.12.2013 10:45, schrieb Eugene Grosbein:> Hi!
>
> Some time ago one of my 9.2-STABLE (r258509) servers crashed
> due to power outage and could not come back by itself when power restored:
> http://www.grosbein.net/freebsd/fsck_ffs.gif
>
> First I thought that was due to missing fsck_y_enable="YES"
> in its /etc/rc.conf, so I just went to single user mode,
> ran "fsck -y" manualy (it successfully fixed all errors)
> and added fsck_y_enable="YES" to /etc/rc.conf
>
> However, today the server had same long-time power outage,
> UPS'es died and when power restored, I've got exactly same problem
> with this server, including fsck_ffs segfault.
>
> # camcontrol devlist
> <WDC WD2003FYYS-02W0B1 01.01D02> at scbus0 target 0 lun 0
(ada0,pass0)
> <WDC WD2003FYYS-02W0B1 01.01D02> at scbus1 target 0 lun 0
(ada1,pass1)
> # gmirror status
> Name Status Components
> mirror/gm0 COMPLETE ada0 (ACTIVE)
> ada1 (ACTIVE)
> # df -h
> Filesystem Size Used Avail Capacity
Mounted on
> /dev/mirror/gm0s1a 1G 136M 790M 15% /
> devfs 1,0k 1,0k 0B 100%
/dev
> /dev/mirror/gm0s1d 503M 335M 127M 72%
/usr
> /dev/mirror/gm0s1e 9,9G 4,1G 5G 45%
/var
> /dev/mirror/gm0s1f 19G 11G 6,4G 65%
/usr/local
> /dev/mirror/gm0s1g 81G 34G 39G 47%
/home
> /dev/mirror/gm0s2a 1,7T 97G 1,5T 6%
/backup
>
> /usr is mounted read-only.
>
> This server is SuperMicro SYS-5016T-MTFB with IPMI 2.0 board
> emulating USB keyboard for IP KVM. The keyboard works fine in BIOS setup
> and in FreeBSD multiuser mode but does not work at all in single user mode,
> so I was forced to enable IPMI SOL (Serial over LAN) feature to be able
> to control the service in the single and learn how to direct serial console
> to COM3 it emulates. So many critical bugs in the STABLE branch, sigh...
>
The first thing I do on my machines is put this into /boot/loader.conf:
hw.ata.wc=0
kern.cam.ada.write_cache=0
For SCSI systems I used to use camcontrol to change the saved mode page
of each drive to disable the write cache.
...and then reboot, and hope for the best WRT hardware not lying to the
kernel (some makers let their drives report completion without
supercapacitors or nvram or battery backup before data was on permanent
storage in the past) - I've never tried that with RAID1 though, but on a
bare UFS2+SU+J it appears to help with avoiding SU+J inconsistencies in
Virtual machines if I forget to shut them down before rebooting the host.
Regarding which combinations of file systems and their options and disk
and bus and geom adapter drivers and ATA chips will reliably ship write
barriers down to the drive (requires NCQ or TCQ), I find that FreeBSD is
underdocumented. Unless the filesystem can ship write barriers all the
way down to the disk through all the layers, disable write caches to
maintain file system recoverability - or disable softupdates and
journalling (but I suppose that would really hurt on the larger partitions).
I would like to be corrected on this because I am wrong, but I fear that
won't happen soon.
There used to be discussions around the FreeBSD 4.x times whether
enabling write caches was a good thing, and people preferred write
caches enabled due to the performance increase, but I have personally
had fsck chicken out on crashed SU+J file systems too often; OTOH I have
not seen corruption with disabled write caches yet. My sample is tiny
though, we're talking of a handful of VirtualBox hosted FreeBSDs mostly,
and one that can boot either on bare metal (2 - 4 times a year) or into
VirtualBox.
Generally, and your application profile permitting, I would probably
also configure computer and UPS such that if the UPS battery is on the
verge of exhaustion, the computer shuts down properly, and if possible,
such that the UPS will wait until it has recharged to a certain
percentage above that minimum (a hysteresis) before powering back on.
Provided that your server's use permits such an extended recovery time
from a prolonged outage at all (along the lines of 'if it's down for an
hours, we can stand another half hour').