czas ext3 fsck a rozmiar partycji


9

Robię konfigurację dużej farmy pamięci masowej i aby uniknąć potrzeby miesięcznego fscks, moim planem jest podzielenie pamięci masowej na wiele mniejszych systemów plików (to dobrze, ponieważ mam dobrze spakowane drzewo plików , więc mogę łatwo mieć oddzielne systemy plików zamontowany na 1/, 2/, 3/, 4/, etc).

Moja trudność polega na znalezieniu jakiegokolwiek wyliczenia, jaki jest „rozsądny” rozmiar systemu plików, aby czasy fsck były podobnie „rozsądne”. Chociaż jestem w pełni świadomy, że czas bezwzględny dla danego rozmiaru zależy w dużej mierze od sprzętu, nie mogę znaleźć żadnego opisu kształtu krzywej dla czasów ext3 fsck przy różnych rozmiarach systemu plików i jakie są inne zmienne ( czy system plików pełen plików w jednym katalogu zajmuje dłużej niż jeden z 10 plikami w każdym z tysięcy katalogów w drzewie; duże pliki kontra małe pliki; pełny system plików vs pusty system plików i tak dalej).

Czy ktoś ma odniesienia do dobrze zbadanych liczb na ten temat? W przeciwnym razie wszelkie anegdoty dotyczące tych zagadnień powinny przynajmniej pomóc w prowadzeniu własnych eksperymentów, jeśli jest to wymagane.

EDYCJA : Aby wyjaśnić: niezależnie od systemu plików, jeśli coś pójdzie nie tak z metadanymi, należy to sprawdzić. To, czy re-fsck oparte na czasie lub montowaniu są włączone czy potrzebne, nie jest kwestią, a jedynym powodem, dla którego proszę o liczby dotyczące ext3, jest to, że jest to najbardziej prawdopodobny system plików do wyboru. Jeśli znasz system plików, który ma wyjątkowo szybki proces fsck, jestem otwarty na sugestie, ale musi to być solidna opcja (twierdzi, że „system plików X nigdy nie potrzebuje fscking!” Będzie się z niego śmiał i wyśmiewał) . Zdaję sobie również sprawę z potrzeby tworzenia kopii zapasowych, a chęć użycia fsck nie zastępuje tworzenia kopii zapasowych, jednak po prostu odrzucenie systemu plików i przywrócenie go z kopii zapasowej, gdy się zepsuje, zamiast fsckowania, wydaje się naprawdę,

Odpowiedzi:


6

Według pracy Mathura i in. (s. 29), e2fsck czas rośnie liniowo wraz z ilością i-węzłów w systemie plików po pewnym punkcie. Jeśli na wykresie jest coś do przejścia, jesteś bardziej efektywny w systemach plików zawierających do 10 milionów i-węzłów.

Przejście na ext4 pomogłoby - pod warunkiem, że twój system plików nie jest załadowany po brzegi, gdzie wzrost wydajności (z powodu nie sprawdzania i-węzłów oznaczonych jako nieużywane) nie ma zauważalnego efektu.


Dzięki za referencje, pomógł mi potwierdzić kilka rzeczy. Przeprowadziłem także własne testy porównawcze, które pokazały liniowy wzrost pokazany w tym artykule.
womble

2

Myślę, że będziesz musiał przeprowadzić własne testy porównawcze. Szybkie wyszukiwanie w Google nic nie ujawniło, z wyjątkiem tego, że ext4 fsck działa znacznie szybciej niż ext3.

Utwórz więc partycje ext3, 100 GB, 200 GB itp. Do rozmiaru używanego dysku. Następnie wypełnij je danymi. Jeśli możesz użyć danych przypominających dane produkcyjne (pliki na katalog, rozkład wielkości plików itp.), To będzie to najlepsze. Zauważ, że po prostu skopiowanie plików z innej partycji urządzenia do tworzenia kopii zapasowych umieści je na dysku idealnie ułożonym i zdefragmentowanym, a zatem w testach zabraknie czasu wyszukiwania głowicy dysku, który będzie pochodził z wielu operacji zapisu / modyfikacji / usuwania.

Musisz także przemyśleć równoległe fscks. Zobacz ostatnie kilka pól w / etc / fstab. Partycje na tym samym dysku fizycznym powinny być wykonywane po kolei; wiele dysków na tym samym kontrolerze może być wykonywanych równolegle, ale uważaj, aby nie przeciążyć kontrolera i spowolnić go.



-1

czy jest jakiś powód, dla którego nie można użyć systemu plików, który nie wymusza na tobie czasu ani fsck opartych na liczbie montowań po ponownym uruchomieniu?

(fscks oparte na czasie naprawdę mnie wkurza - dla serwera o długim czasie działania prawie gwarantuje, że będziesz musiał wykonać pełny fsck przy każdej aktualizacji jądra).

w każdym razie XFS jest jednym z systemów plików kronikowania, które nie wymuszają fsck. warte zobaczenia.


inną opcją jest użycie Nexenta (jądro opensolaris, debian userland), co dałoby ci ZFS. <a href=" nexenta.org/"> http://www.nexenta.org/</A >
cas

3
Kiedy system plików ulega uszkodzeniu, bez względu na to, co to jest (extN, XFS, ZFS, cokolwiek), lub niezależnie od tego, czy masz czas / liczbę montowań, potrzebuje fsck. Chcę mieć pewność, że pojedynczy uszkodzony system plików nie zajmie zbyt wiele czasu fsck.
womble

1
tak, oczywiście fs potrzebuje fsck, jeśli został uszkodzony. użycie fs, takiego jak XFS, nie wyeliminuje ich, nie powinieneś próbować ani nawet tego chcieć. Nie powiedziałem nic, co inaczej można by interpretować. Chodzi mi o to, że zmuszanie fsck tylko dlatego, że minęło X wiele dni lub Y wiele montowań od ostatniego fsck jest niepotrzebne i denerwujące, a być może nawet „ograniczające karierę”, szczególnie jeśli twoi użytkownicy lub twoja firma czekają na serwer plecy. Państwo może wyeliminować te niepotrzebne fscks, i tak robi to dobrze.
cas

Jakkolwiek może być dobre (ale nie musi), nie odpowiada na postawione pytanie.
womble
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.