Jak długo fsck może przyjąć wolumin 30 TB?

W połowie listopada VPS, który wynajmuję od firmy hostingowej, przestał odpowiadać. Kiedy skontaktowałem się z pomocą techniczną, wyjaśnili, że awaria zasilania w centrum danych spowodowała wymuszony restart i fsck. W końcu zapytałem, dlaczego to trwa tak długo, i powiedziano mi, że rozmiar woluminu wynosi 30 TB. Ostatni raz otrzymałem aktualizację w lutym i nie odpowiedzieli na moje ostatnie zapytanie.

Rozumiem, że fsck może być bardzo wolny dla niektórych systemów plików, ale czy jest możliwe, aby fsck zajął 6 miesięcy na wolumenie 30 TB, czy też powinienem założyć, że ta firma hostingowa mnie okłamuje, aby nadal płacić rachunek co miesiąc?

fsckprędkość zależy głównie od liczby plików i sposobu ich rozproszenia w odpowiednim katalogu. To powiedziawszy, 6-miesięczny okres na fsckabsurd jest absolutnie absurdalny: powinien był zostać ukończony najwyżej za kilka godzin, zwłaszcza jeśli korzystasz xfsz szybkiego xfs_repairnarzędzia. Tutaj możesz znaleźć fsckbieg w skali - wszystkie ukończone w mniej niż godzinę (3600s). Tak więc nie jest możliwe, że Twój fscknadal działa.

W każdym razie nieoczekiwana utrata mocy nie spowoduje pełnego uderzenia fsck, a jedynie bardzo szybkie (kilka sekund) powtórzenie dziennika . Jeśli jednak niektóre kluczowe pliki zostaną uszkodzone, system operacyjny może nie zostać uruchomiony.

Ale prawdopodobnie właśnie cię okłamali. Powinieneś natychmiast przestać płacić, poprosić o wyjaśnienie i ubiegać się o całkowity zwrot pieniędzy.

Przypuszczenie: ich system wykorzystuje RAID bez BBU / FBWC (lub nawet RAID programowy) z wszystkimi możliwymi pamięciami podręcznymi zapisu (w tym również z samych dysków twardych) ustawionymi na najbardziej agresywnych ustawieniach, aby uzyskać maksymalną wydajność przy minimalnych kosztach. Awaria zasilania w takiej konfiguracji może spowodować, że system plików kronikowania pozostanie w stanie, w którym nie można ufać kronikowi i nie można go użyć do odzyskiwania. Problem polega na tym, że taki system agresywnie zmienia kolejność i odkłada zapis, co oznacza, że ​​zapis do dziennika może zostać zapisany z efektem utraty akcji danych ... lub utraty pozycji dziennika w wyniku akcji danych, która była konsekwencją.

Odzyskiwanie takiego systemu po awarii w najgorszym przypadku może oznaczać, że musisz wykonać „powolne” fsck / repair, które faktycznie sprawdzają wszystkie struktury systemu plików takimi, jakie są, co może zająć dzień lub dwa dla 30 TB .... i to nie jest prawdopodobne, że będziesz musiał uruchomić wiele cykli napraw. Dodaj do tego, że personel może nie zawsze być w stanie to monitorować, możesz łatwo sprowadzić się do jednego fsck wykonywanego na tydzień. Prawdopodobnie się poddali i zapomnieli.

W przypadku większości systemów plików będzie to znacznie szybsze, nawet jeśli wystąpią błędy, ponieważ zwykle sprawdzane są tylko metadane.

W najgorszym przypadku może odczytać cały dysk ( np. Coś w rodzaju fsck.ext4 -cc /dev/sdanieniszczącego testu zapisu na każdym bloku), co może zająć kilka dni dla 30 TB. Jeśli znasz prędkość napędów, możesz obliczyć rozmiar / prędkość . W przypadku dysku twardego z kopiowaniem około 100 MB / s kilka TB może zająć więcej godzin, niż większość ludzi by się spodziewała.

Gdyby to był twój serwer, mógłbyś mieć problem, że uruchamia się, a następnie zawiesza się, gdy fsckpyta cię, czy chcesz naprawić błąd. Ale administrator centrum danych nie pozostawi fsckzawieszenia przez 6 miesięcy, podczas gdy wszystkie VPS są offline.

Więc albo cię okłamują, albo istnieje ogromne nieporozumienie. Lub działali fsck jakiś czas temu i nie informowali cię o nowym problemie po jego zakończeniu.