kernel: panic: ffs_blkfree: freeing free block

Po zainstalowaniu czyściutkiego nowego systemu FreeBSD 8.0-RELEASE, pracując już po SSH (putty) podczas instalowania odpowiednich portów (polecenie: make install clean), system zaczął się dziwnie i niestabilnie zachowywać. Skutkiem niestabilności były restarty systemu w zasadzie z niewyjaśnionych przyczyn.
Przykład: port się kompiluje i nagle restart, putty traci łączność z serwerem, ponownie zalogowanie do systemu, sprawdzenie uptime, gdzie z reguły było kilka sekund/minut. Na koniec dmesg, który potwierdzał restart serwera.
Po każdym restarcie szukałem informacji w logach (/var/run, /var/log). Jedynie co znajdywałem to informację o restarcie.
Ciekawostką było to, że restarty pojawiały się w dowolnym momencie i tylko podczas pracy dysku (read/write). A czasami w logach nie widać nieprawidłowej pracy dysków.
Nieufność do nowych dysków Caviara (tylko 320GB) pokierowały moją intuicją, aby sprawdzić logi S.M.A.R.T. (portem smartmontools). Ale niestety, niczego złego tam nie znalazłem (No Errors Logged).
Zmieniłem kable. Żadnych zmian. Podłączyłem monitor i… przy restartach miałem coś takiego:

Jan 19 09:13:41 fox syslogd: kernel boot file is /boot/kernel/kernel
Jan 19 09:13:41 fox kernel: dev = ad0s1f, block = 1, fs = /usr
Jan 19 09:13:41 fox kernel: panic: ffs_blkfree: freeing free block
Jan 19 09:13:41 fox kernel: cpuid = 0
Jan 19 09:13:41 fox kernel: Uptime: 44m25s
Jan 19 09:13:41 fox kernel: Cannot dump. No dump device defined.
Jan 19 09:13:41 fox kernel: Automatic reboot in 15 seconds – press a key on the console to abort
Jan 19 09:13:41 fox kernel: Rebooting…

Może powinienem ustawić inny poziom logowania demona syslogd? Może wtedy zobaczyłbym powyższe zapisy w logach?
Jednakże z powodu braku czasu zarzuciłem temat wyszukiwarce google.
Okazało się, że freeing free block podczas pracy systemu i dysku, to bug samego systemu, z którym już od kilku lat borykają się autorzy dystrybucji freeBSD.
Wg ich sugestii należało wyłączyć tzw. softupdates dla danego systemu plików (u mnie native freebsd –> ufs).
Podobno softupdates przyspiesza pracę na dysków zwalniając odpowiednie bloki (freeing free blocks) wg zaawansowanych algorytmów.
Sprawdziłem więc jak było u mnie:

fox# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)

Postanowiłem wyłączyć softupdates dla /usr, na którym występował problem.
Nie można tego było zrobić on-the-fly (podczas pracy systemu), ponieważ /usr była w użyciu, a fix można wykonać tylko i wyłącznie na odmontowanej partycji. Jedyna droga to boot‚owanie systemu w trybie Single user mode.
Polecenie

#tunefs -n disable /usr

wyłącza softupdates na /usr.
Jeszcze szybko sprawdziłem aktualny stan ustawień systemu plików

fox# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local)
/dev/ad0s1d on /var (ufs, local, soft-updates)

i reboot.
Jakoś do dzisiaj nie widać wyraźnego spadku wydajności pracy dysku po wyłączeniu softupdates.
Ważniejszym jest, że restartów już nie ma. Nic tylko się cieszyć.
Jako ciekawostkę mogę dodać, iż serwerów freeBSD postawiłem już całkiem sporo, a taki przypadek pojawił się po raz pierwszy.
Może to jednak ten Caviar? Może powinienem wybrać Seagate albo Maxtor? 🙂

p.s. polecam też HandBook‚a freeBSD o Tuning Disks: http://www.freebsd.org/doc/handbook/configtuning-disk.html