Używam FreeBSD 8.0, a następnie migawki 8.0-stable-February 2010 do eksperymentowania z ZFS przez kilka miesięcy. System ma kilka niezależnych 4-dyskowych pul RAIDZ1. Na początku wydawało się, że wszystko idzie mniej lub bardziej idealnie, chociaż napotykałem coraz bardziej niepokojące problemy, które sprawiają, że myślę, że w pewnych szczególnych okolicznościach i konfiguracjach rozsądnie jest unikać takiej konfiguracji. Mój pierwszy problem niekoniecznie dotyczy stabilności / funkcjonalności nie samych ogólnie FreeBSD / ZFS, ale raczej niezawodności i funkcjonalności niektórych sterowników urządzeń i napędów dysków w FreeBSD. Okazało się, że domyślny sterownik ata / ide nie obsługiwał kontrolera, którego używam, ale sterownik pamięci masowej obrazu krzemowego siis miał wymaganą obsługę SATA multiplikatora portów, aby dyski działały z FreeBSD 8. Jednak po dokładniejszym sprawdzeniu, czy kod sterownika nie jest tak naprawdę gotowy do produkcji, IMHO - nie z wdziękiem poradził sobie z pierwszym błędem związanym z dyskiem / przekroczeniem limitu czasu / ponownej próby, który spowodował, że napęd w tablicy wykonał coś w rodzaju opóźnienia odpowiedzi na kilkadziesiąt sekundy. Nie wiem dokładnie, co się stało, ale minęło około minuty, zanim tablica przekroczyła limit czasu, zresetowała i przywróciła działanie, w którym to czasie każdy dysk w tablicy został „utracony” ze stanu operacyjnego i spowodował nieodwracalny błąd danych na wyższym poziomie systemu plików. AFAICT nawet opiekun sterownika SIIS twierdzi, że obsługa limitu czasu / resetowania sterownika nie jest jeszcze w pełni ukończona / solidna / zoptymalizowana. W porządku, ale chodzi o to, bez względu na to, jak dobry jest system operacyjny lub ZFS, jeśli masz zawodny dysk, kontroler lub sterownik, z pewnością może to zepsuć ogólne operacje na tyle, aby spowodować poważne błędy i utratę danych pomimo ZFS. Również żądania SMART diagnostyki nie działają z tym konkretnym sterownikiem kontrolera. Co do tego, co spowodowało błąd .. niestabilne dyski / oprogramowanie Seagate? Nie wiem, ale błąd jednego dysku powoduje „awarię” całej macierzy, mimo że RAIDZ pokonuje cały punkt niezawodności RAIDZ. Zachowanie po problemie ze statusem zpool scrup / zpool i in. glin. było również trochę podejrzane i nie jest do końca jasne, czy ten proces diagnostyki / odzyskiwania działał poprawnie na poziomie ZFS / ZPOOL; z pewnością otrzymałem kilka mieszanych komunikatów o statusach błędów i usuwaniu błędów itp. glin. Wskazania błędu zniknęły po ponownym uruchomieniu komputera, pomimo braku wyraźnego polecenia zpool clear; może to jest zamierzone, ale jeśli tak, to nie było sugerowane przez wynik statusu zpool.
Potencjalnie poważniej coś wydaje się NIEWIDOCZNIE popsuć podczas pracy po kilku dniach bezczynności, w której duże części tablicy zawierającej wiele systemów plików (ZFS) po prostu „zniknęły” z listy w (ls) i z normalnego dostępu I / O . IIRC df -h, ls itp. Nie zgłosiły systemów plików nawet jako istniejące, podczas gdy status zpool / status zpool nadal wskazywał oczekiwaną ilość zajętej pamięci w puli, ale nie został uwzględniony przez żadnego z zamontowanych lub odmontowane systemy plików. / var / log / messages nie zawierał żadnego komunikatu o błędzie, a przed tym problemem operacje przebiegały całkowicie normalnie. Lista zpool / status zpool nie wskazują na problemy z pulą. Odmontowanie zfs -a nie powiodło się ze wskazaniem zajętości bez wyraźnego powodu związanego z interaktywnym użytkowaniem przez kilka minut przed odmontowaniem ostatniego z zamontowanych systemów plików zfs. Ponowne uruchomienie i ponowne sprawdzenie / var / log / messages, status zpool, lista zpool nie informowała o żadnym problemie. Wcześniej brakujące systemy plików zresetowały się ponownie, gdy został o to poproszony ręcznie, i początkowo wydawały się mieć poprawną zawartość, ale po około minucie montowania różnych systemów ZFS w puli zauważono, że niektóre ponownie nieoczekiwanie zniknęły. Możliwe, że ja
To prawda, że korzystam ze stabilnej migawki z 10 lutego, która NIE jest polecana do użytku produkcyjnego, ale z drugiej strony kilka względnie godnych uwagi poprawek znanych problemów z ZFS / pamięcią masową wprowadzono w stabilnej gałęzi od wydania 8.0, więc bieżąca wersja 8.0 może być niezadowalające pod względem niezawodności / funkcji z powodu tych problemów dla niektórych osób.
W każdym razie zaledwie kilka tygodni dość lekkich testów zaowocowało wystarczającą liczbą potencjalnie katastrofalnych problemów z niezawodnością / funkcjonalnością, z których nie wszystkie wydają się mieć związek ze szczególnymi brakami dysków / kontrolerów / sterowników pamięci masowej, które jestem ostrożny, jeśli chodzi o zaufanie do FBSD 8.0 + ZFS do użytku produkcyjnego / niezawodnościowego bez bardzo dokładnie kontrolowanej konfiguracji sprzętu i oprogramowania oraz strategii tworzenia kopii zapasowych offline.
OpenSolaris jest teraz i tak nie do przyjęcia, nawet jeśli chciałbyś go uruchomić - mając na uwadze, że istnieją poważne znane problemy z deduplikacją ZFS, które praktycznie uniemożliwiają jej użycie, i to i inne problemy wydają się skutkować rekomendacją, aby poczekać jeszcze kilka wersji łatek, które pojawią się przed zaufaniem OpenSolaris + ZFS, szczególnie w systemie deduplikacji. Wydaje się, że B135 / B136 po prostu zaginęło bez wyjaśnienia, podobnie jak główna wersja systemu operacyjnego 2010.03. Niektórzy twierdzą, że Oracle wypowiada się na temat opóźnień w harmonogramie, ale że spodziewane kody zostaną ostatecznie wydane z opóźnieniem, podczas gdy inni zastanawiają się, czy kiedykolwiek zobaczymy pełny zestaw oczekiwanych funkcji opracowywanych przez Sun jako przyszłych wersji open source przez Oracle, biorąc pod uwagę przejście własności / przywództwa / zarządzania.
IMHO Trzymałbym się tylko robienia kopii lustrzanych i tylko z bardzo dobrze sprawdzonymi / stabilnymi sterownikami kontrolerów pamięci i modelami napędów dysków dla optymalnej niezawodności ZFS w FreeBSD 8, i prawdopodobnie czekałbym nawet na 8.1.