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
Dzięki, twój artykuł mi bardzo pomógł. Ja miałem tan sam problem z nowym HDD Segate 500GB. Testowałem na dwóch różnych jednostkach. Co sądzisz aby wyłączyć softupdate również na partycjach /tmp i /var? Ciekawe czy na nich również może wystąpić ten problem?
Na innych partycjach (partitions) lub etykietach (labels) jeszcze nie widziałem tego błędu. Warto też stworzyć sobie skrypty shellowe okresowo (cronem) mierzące stan dysku narzędziem do odczytu informacji S.M.A.R.T. (smartmontools)
Już się cieszyłem, że system będzie śmigał stabilnie, w końcu z tego słynie freebsd, a tu podczas wykonywania polecenia ‚portsnap extract’ w pewnym momencie system się zwiesza i na monitorze pojawia się ‚kernel panic: bufwrite buffer is not busy???…’ Zaczynam się zrażać co do tego systemu z powodu tych zwiech, po świeżej instalce. Chciałem się przesiąść z NND na FreeBsd, gdyż NND nie jest już rozwijane, a szkoda bo od trzech lat mam na nim postawiony router, serwer www, poczty i inne, jak dotąd nie zaliczył żadnej zwiechy.
ja bym na Twoim miejscu szukał rozwiązania w sieci, też miałem różne zwiechy i tu raczej chodziło o sprzęt. dziwne bo czasami wg freeBSD karta grafiki gryzie się z płytą główną, itp.