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ę,
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.
źródło
http://lmgtfy.com/?q=fsck+benchmark
wygląda na to, że fsck na systemach plików ext4 jest znacznie szybszy niż na ext3, a niektóre raporty o ext4 fsck są 10 lub nawet więcej razy szybsze niż ext3.
dwa dość interesujące artykuły z tego wyszukiwania to:
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ ihttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
źródło
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.
źródło