Date: Wed, 04 Dec 2013 00:24:05 +0100 From: Matthias Andree <matthias.andree@gmx.de> To: freebsd-stable@freebsd.org Subject: Re: fsck_y_enable is broken for SUJ as well as fsck_ffs Message-ID: <529E6815.3080208@gmx.de> In-Reply-To: <529DA855.9040406@rdtc.ru> References: <529DA855.9040406@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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').
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?529E6815.3080208>