Czy FUD dotyczący ext4 jest uzasadniony? Czy byłby bezpieczny w użyciu w niektórych systemach produkcyjnych?

Zastanawiam się, czy korzystanie z ext4 jest bezpieczne na moich serwerach. Ale słyszałem o tym tyle FUD, że martwię się.

Nasz system może stracić część danych i nie byłby to zbyt duży problem. Nawet dane z całych dni nie zmieszałyby zbyt wielu piór. A nasz system może zdecydowanie skorzystać z opóźnionego zapisu.

To powiedziawszy, pełne przywrócenie systemu plików z kopii zapasowej zajęłoby dni i byłoby niedopuszczalne.

Jakieś doświadczenia lub świadome opinie na ten temat?

Szczerze mówiąc, wstrzymałbym się teraz z ext4 do użytku produkcyjnego.

Istnieją inne opcje, jeśli masz rzeczywiste problemy z wydajnością systemu plików (i rozumiem tę sytuację, w moim ostatnim zadaniu mieliśmy ograniczenia wydajności w aplikacji z powodu ext3). W zależności od wybranej dystrybucji możesz używać jfs, xfs lub reiserfs. Wszystkie trzy generalnie przewyższają ext3 na różne sposoby, a wszystkie trzy są teraz znacznie bardziej przetestowane i stabilne niż ext4.

Tak więc moja rekomendacja składałaby się z wielu części. Najpierw dokładnie zbadaj, aby upewnić się, że optymalizujesz we właściwym miejscu. Przetestuj aplikację na różnych systemach plików i upewnij się, że wydajność została poprawiona na tyle, aby zmiana systemu plików była poprawna.

Ponadto, w zależności od aplikacji, dodanie większej ilości pamięci RAM może poprawić wydajność. Linux domyślnie korzysta z dowolnej pamięci RAM, która nie jest przypisana do aplikacji jako pamięć podręczna dysku. Czasami posiadanie kilku GB „nieużywanej” pamięci RAM może znacznie zwiększyć wydajność w urządzeniach o dużej aktywności dysku.

Na koniec, jakie są twoje wymagania dotyczące osi czasu tutaj? Gdyby ext3 go nie wyciął i musiałbym dziś zbudować maszynę z innym systemem plików, prawdopodobnie użyłbym XFS lub JFS. Gdybym mógł to zepchnąć przez 6-8 miesięcy, prawdopodobnie poczekam i zobaczę, jak ukształtował się ext4.

Z pewnością Ubuntu 9.04 (jaunty) wciąż pracuje nad błędami ext4 w swojej wersji jądra 2.6.28. Niektóre błędy wydają się być tylko w jądrze ubuntu, a nie w głównej linii, ale to wskazuje, że jeśli masz jądro inne niż główne, możesz napotkać podobne problemy.

Ta strona jest wyszukiwaniem problemów z ext4, które mogą być warte przejrzenia. Jednym z aktualnych (6 maja 2009 r.) Poważnych problemów, które powodują blokowanie jądra, jest problem 330824 . A poprzedni problem (już ustalona) zaangażowanych utraty danych. Ale nie słyszałem o żadnej utracie całego systemu plików i myślę, że byłaby to wielka wiadomość, gdyby tak się stało.

Powiedziałbym więc, że nie jest w pełni gotowy na najwyższy czas. Jeśli naprawdę tego potrzebujesz, warto skonfigurować serwer testowy, aby się z nim bawić. Na razie trzymałem się jądra głównego i mierzyłem wzrost wydajności - jeśli wzrost jest dramatyczny, a testy warunków skrajnych nie wykazują żadnych problemów, warto spróbować ...

Uważam, że opinie z http://web.luchs.at są bardzo interesujące. Używali ext4 na serwerach opartych na Debianie Lenny i to wydaje się działać świetnie!

Jeśli nie martwisz się przekroczeniem limitów ext3, nie zawracałbym sobie głowy. Chociaż ext4 oferuje szereg ulepszeń, większość z nich nie jest skierowana do zwykłych użytkowników.

Zasadniczo najbezpieczniej jest korzystać z najbardziej dojrzałej technologii, która wygodnie dopasuje się do twoich potrzeb w dającej się przewidzieć przyszłości. Jeśli nie potrzebujesz nowych, wymyślnych rzeczy, dodajesz ryzyko (nawet niewielkie) bez żadnej korzyści.

To powiedziawszy, pełne przywrócenie systemu plików z kopii zapasowej zajęłoby dni i byłoby niedopuszczalne.

Następnie trzymaj się ext3, jako bonus, każdy slob z kluczem USB Fedory może zamontować dysk, jeśli do tego dojdzie.

ext4 jest wciąż bardzo nowy. Konserwatywne podejście polegałoby na użyciu ext3 lub czegoś o znanej charakterystyce niezawodności. Polecam ext4 w tym momencie tylko dla systemów, w których niezawodność nie jest krytyczna lub gdzie nowe funkcje w ext4 znacznie przewyższają ryzyko utraty danych.