System plików XFS jest uszkodzony w RHEL / CentOS 6.x - Co mogę z tym zrobić?


28

Najnowsze wersje RHEL / CentOS (EL6) przyniósł kilka interesujących zmian w systemie plików XFS ja zależała w dużym stopniu od ponad dziesięciu lat. Spędziłem część zeszłego lata, ścigając sytuację rzadkich plików XFS wynikającą ze źle udokumentowanego backportu jądra. Inni mieli niefortunne problemy z wydajnością lub niespójne zachowanie od czasu przejścia na EL6.

XFS był moim domyślnym systemem plików dla partycji danych i wzrostu, ponieważ oferował stabilność, skalowalność i dobry wzrost wydajności w porównaniu z domyślnymi systemami plików ext3.

Wystąpił problem z XFS w systemach EL6, które pojawiły się w listopadzie 2012 r. Zauważyłem, że moje serwery wykazują nienormalnie wysokie obciążenia systemu, nawet gdy są bezczynne. W jednym przypadku nieobciążony system wykazywałby stałą średnią wartość obciążenia wynoszącą 3+. W innych wystąpił wzrost obciążenia o 1+. Wydaje się, że liczba zamontowanych systemów plików XFS wpływa na nasilenie wzrostu obciążenia.

System ma dwa aktywne systemy plików XFS. Obciążenie wynosi +2 po aktualizacji do dotkniętego jądra. wprowadź opis zdjęcia tutaj

Kopanie głębiej, znalazłem kilka tematów na liście dyskusyjnej XFS , które wskazywały na zwiększoną częstotliwością xfsaildprocesu siedzi w STAT D państwa. Odpowiednie wpisy śledzenia błędów CentOS i błędów Bugzilli w Red Hat przedstawiają specyfikę problemu i stwierdzają, że nie jest to problem z wydajnością; tylko błąd w raportowaniu obciążenia systemu w jądrach nowszych niż 2.6.32-279.14.1.el6 .

WTF?!?

W jednorazowej sytuacji rozumiem, że raportowanie obciążenia może nie być wielkim problemem. Spróbuj zarządzać tym za pomocą NMS i setek lub tysięcy serwerów! Zostało to zidentyfikowane w listopadzie 2012 r. W jądrze 2.6.32-279.14.1.el6 pod EL6.3. Jądra 2.6.32-279.19.1.el6 i 2.6.32-279.22.1.el6 zostały wydane w kolejnych miesiącach (grudzień 2012 i luty 2013) bez zmiany tego zachowania. Od czasu zidentyfikowania tego problemu pojawiła się nawet nowa, niewielka wersja systemu operacyjnego. EL6.4 został wydany i jest teraz w jądrze 2.6.32-358.2.1.el6 , który wykazuje takie samo zachowanie.

Miałem nową kolejkę kompilacji systemu i musiałem obejść ten problem, albo blokując wersje jądra w wersji przed listopadem 2012 dla wersji EL6.3, albo po prostu nie używając XFS, wybierając ext4 lub ZFS , z poważnym ograniczeniem wydajności dla konkretnej aplikacji niestandardowej działającej na szczycie. Ta aplikacja w dużej mierze opiera się na niektórych atrybutach systemu plików XFS, aby uwzględnić wady w projekcie aplikacji.

Idąc za płatną stroną bazy wiedzy Red Hat , pojawia się wpis z informacją:

Po zainstalowaniu jądra 2.6.32-279.14.1.el6 obserwuje się wysoką średnią obciążenia. Wysoka średnia obciążenia jest spowodowana przejściem xfsaild w stan D dla każdego urządzenia sformatowanego w systemie XFS.

Obecnie nie ma rozwiązania tego problemu. Obecnie jest śledzony za pośrednictwem Bugzilli # 883905. Obejście problemu Zmień wersję zainstalowanego pakietu jądra na wersję niższą niż 2.6.32-279.14.1.

(z wyjątkiem obniżenia jądra, które nie jest opcją w RHEL 6.4 ...)

Mamy więc ponad 4 miesiące od pojawienia się tego problemu i nie planujemy żadnej prawdziwej poprawki dla wersji systemu operacyjnego EL6.3 lub EL6.4. Jest proponowana poprawka do EL6.5 i łatka na jądro dostępna ... Ale moje pytanie brzmi:

W jakim momencie sensowne jest odejście od jąder i pakietów dostarczanych przez system operacyjny, gdy opiekun nadrzędny zepsuje ważną funkcję?

Red Hat wprowadził ten błąd. One powinny zawierać poprawki do jądra o errata. Jedną z zalet korzystania z systemów operacyjnych dla przedsiębiorstw jest to, że zapewniają one spójny i przewidywalny cel platformy . Ten błąd zakłócił działanie systemów już produkowanych podczas cyklu łatania i zmniejszył zaufanie do wdrażania nowych systemów. Chociaż mógłbym zastosować jedną z proponowanych poprawek do kodu źródłowego , jak bardzo jest to skalowalne? Wymagałoby to zachowania czujności, aby aktualizować się wraz ze zmianami systemu operacyjnego.

Jaki jest odpowiedni ruch tutaj?

  • Wiemy, że można to naprawić, ale nie kiedy.
  • Wspieranie własnego jądra w ekosystemie Red Hat ma własny zestaw ostrzeżeń.
  • Jaki wpływ ma na kwalifikowalność do wsparcia?
  • Czy powinienem po prostu nałożyć działające jądro EL6.3 na nowo budowane serwery EL6.4, aby uzyskać odpowiednią funkcjonalność XFS?
  • Czy powinienem tylko poczekać, aż zostanie to oficjalnie naprawione?
  • Co to mówi o braku kontroli nad cyklami wydań Linuxa dla przedsiębiorstw?
  • Czy poleganie na systemie plików XFS było tak długo błędem planowania / projektowania?

Edytować:

Ta łatka została włączona do najnowszej wersji jądra CentOSPlus ( kernel-2.6.32-358.2.1.el6.centos.plus ). Testuję to na moich systemach CentOS, ale to niewiele pomaga serwerom opartym na Red Hat.


3
Zawsze byłem przekonany, że jeśli używasz EL6 i płacisz wsparcie RHEL, to ich zadaniem jest to dla Ciebie naprawić?
Tom O'Connor,

6
Tak ... Red Hat to naprawi ... według własnego harmonogramu !! - Ten problem pojawił się pod koniec 2012 roku. Nadal nie został rozwiązany. To nie trafi do naprawy aż do wydania RHEL 6.5, więc technicznie, oni dbanie o niego ...
ewwhite

Cóż, z nastawieniem, które pokazuje Red Hat (patrz narzędzie do śledzenia błędów), szczerze mówiąc, nie wierzę, że przeszkadzają już XFS. Niestandardowe jądro ma tutaj sens, ale po co płacić za wsparcie? Może CentOS to twoja ścieżka ...
Pauska

5
<rant> Rozumiem twoją frustrację, byłem wcześniej odpowiedzialny za mieszane środowisko RHEL / CentOS, a RH sprawia, że ​​czasami naprawdę trudno jest utrzymywać zapasy, widząc, jak nieustannie „ignorują”, aby naprawić krytyczne błędy, a czasem siebie . Następnie planują naprawić kolejną główną wersję, ale ponieważ nie obsługują aktualizacji do następnej głównej wersji, jest to mało pomocne. W pewnym momencie zdecydowałem się porzucić ich oficjalne jądra na niektórych urządzeniach RHEL5 po prostu dlatego, że musiałem to zrobić z powodu braku konkretnej funkcji. </rant>
Adrian Frühwirth

1
@ MartinSchröder SLES nie jest szczególnie popularny w USA, ale może być opcją. Sam XFS nie jest zepsuty, ale radzi sobie z tym Red Hat. Warto to rozważyć.
ewwhite

Odpowiedzi:


14

W jakim momencie sensowne jest odejście od jąder i pakietów dostarczanych przez system operacyjny, gdy opiekun nadrzędny zepsuje ważną funkcję?

„W miejscu, w którym jądro lub paczki dostawcy są tak okropnie zepsute, że wpływają na twoją działalność” - moja ogólna odpowiedź (przypadkowo dotyczy to również momentu, w którym mówię, że sensowne jest zacząć szukać sposobów na odejście od relacji z dostawcą) .

Zasadniczo, jak powiedzieliście ty i inni, RedHat wydaje się nie chcieć łatać tego w swoim rozproszonym jądrze (z jakiegokolwiek powodu). To prawie pozostawia Cię w sytuacji, gdy musisz rzucić własne jądro (na bieżąco aktualizować je, utrzymywać własny pakiet i instalować go w systemach z Puppet lub podobnym, lub uruchomić serwer pakietów Yum lub cokolwiek innego) użyj dzisiaj może odnosić się) lub zabrać swoje kulki i iść do domu.


Tak, wiem, że zabranie kulek i powrót do domu jest często kosztowną propozycją - zmiana dostawców systemów operacyjnych jest ogromnym problemem, szczególnie w świecie Linuksa, w którym smaki są diametralnie różne z administracyjnego punktu widzenia.
Inne opcje, takie jak całkowite przejście na CentOS, również nie są atrakcyjne (ponieważ tracisz wsparcie i nadal otrzymujesz zasadniczo kod RedHata zbudowany przez kogoś innego, abyś nadal miał ten błąd).

Niestety, chyba że wystarczająca liczba ludzi (tj. „Wielkie firmy) zabierze swoje kulki i pójdzie do domu, sprzedawca nie będzie tak bardzo obchodził się z przekręcaniem ludzi przez wysyłanie złego kodu i nie naprawianie go.


14

Zostało to naprawione ( cicho ) przez Red Hat 23 kwietnia 2013 r. W jądrze RHEL-2.6.32-358.6.1.el6 w ramach aktualizacji 6.4 errata ...


2
20 tygodni po zgłoszeniu błędu, 2 tygodnie po poście tutaj, Czy myślisz, że może redhat widział wszystkie rady mówiące „chodzić”
Jasen

Może? Nie jestem pewny.
ewwhite

3

Jeśli musisz załatać jądro RHEL, to można to zrobić samemu i być oficjalnie obsługiwane na tym jądrze, to po prostu trzeba im to poświadczyć.

W umowie wsparcia RHEL są takie postanowienia - ISTR jest ograniczony do 1 lub 2 na kwartał lub rok, ale nie pamiętasz tego na pewno.


Bardzo dobrze wiedzieć!
ewwhite

To nie jest poprawne. Możesz poprosić Red Hat o przyspieszoną poprawkę, ale istnieją kryteria, które musi spełnić ten problem, aby ją dostarczyć, oraz kilka różnych sposobów dostarczenia obsługiwanej przyspieszonej poprawki. Jeśli przejdziesz do ponownej kompilacji własnego jądra, jądro to nie jest obsługiwane przez Red Hat.
suprjami

Mam klienta, który właśnie to robi. Nie sądzę, że robią to dla wszystkich, ale robią to.
MikeyB
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.