Dlaczego duża liczba plików wyczerpuje inody w domowym NAS zanim skończy się miejsce na dysku?

Wysoka liczba plików może wyczerpać zapas inodów w domowym NAS zanim skończą się bloki danych. Efekt wygląda sprzecznie: ekran pojemności może pokazywać gigabajty lub terabajty wolnego miejsca, a mimo to przesyłanie, kopia zapasowa, kontener lub indeksowanie nie mogą utworzyć kolejnego pliku.

To jest limit systemu plików, a nie uniwersalna właściwość każdego NAS. Klasyczna awaria jest najłatwiejsza do zauważenia na ext4 i podobnych systemach plików z określoną liczbą inodów, podczas gdy XFS i Btrfs alokują metadane inaczej. Typ systemu plików decyduje więc, czy „wolne inody” to właściwa miara, czy tylko część diagnozy.

Domowy NAS może wyczerpać sloty obiektów przed blokami danych

Bezpośrednią przyczyną jest to, że dane pliku i tożsamość pliku zużywają różne zasoby. W ext4 inode zapisuje metadane takie jak znaczniki czasu, właścicielstwo, mapowanie bloków i rozszerzone atrybuty, podczas gdy wpis katalogowy łączy nazwę z inode. Dokumentacja jądra Linuksa ext4 inode opisuje tabelę inode jako liniową tablicę rozproszoną w grupach bloków.

Każdy nowy zwykły plik zazwyczaj potrzebuje inoda, ale rozmiar w bajtach nie determinuje, ile inodów jest potrzebnych. Film o wielkości 100 GB może zajmować jeden inode, podczas gdy milion małych plików cache może wymagać około miliona inodów. Katalogi i dowiązania symboliczne to również obiekty systemu plików, podczas gdy wiele twardych dowiązań do tego samego pliku dzieli jeden inode.

Wolne bloki mogą więc pozostać dostępne po przypisaniu ostatniego wolnego inoda. W tym momencie NAS w zasadzie ma jeszcze miejsce na więcej danych plików, ale brakuje mu tożsamości metadanych potrzebnej do utworzenia kolejnego obiektu. Pojemność i liczba obiektów są na tyle niezależne, że oba parametry muszą być monitorowane.

Dlaczego małe pliki szybciej zużywają inody niż pojemność

Małe pliki tworzą wysoką gęstość obiektów: wiele tożsamości jest potrzebnych dla stosunkowo niewielkiej ilości danych. Plik o zerowej wielkości nadal wymaga metadanych, a drzewo katalogów dodaje własne inody katalogów, zanim policzone zostaną pliki w nim zawarte. Dlatego obciążenie może zużywać sloty plików znacznie szybciej niż reklamowane terabajty NAS.

W ext4 narzędzie tworzące może obliczyć liczbę inode na podstawie stosunku bajtów na inode lub przyjąć jawnie określoną liczbę inode. Opcje alokacji inode mke2fs wskazują, że większy stosunek bajtów na inode tworzy mniej inode i że stosunku tego nie można zmienić po utworzeniu systemu plików, chociaż zmiana rozmiaru utrzymuje skonfigurowany stosunek przez dodanie inode z nową przestrzenią.

Prosty model planowania to przybliżona liczba inode = rozmiar systemu plików ÷ stosunek bajtów na inode. Przy hipotetycznym stosunku 16 KiB, 1 TiB odpowiada około 67 milionom slotów inode przed uwzględnieniem narzutu formatowania i ograniczeń systemu plików. To ilustracja, a nie uniwersalna domyślna wartość NAS: profile formatowania i implementacje systemów plików wybierają różne polityki.

Co się zmienia, gdy zostanie przydzielony ostatni wolny inode

W klasycznym przypadku wyczerpania operacje wymagające nowego inode zaczynają się nie powodzić. Nowe przesyłania, katalogi, pliki tymczasowe, wyodrębnione elementy archiwum i pliki stanu aplikacji mogą być odrzucane, mimo że istniejące pliki nadal można odczytywać. Istniejący plik może również rosnąć, jeśli pozostają wolne bloki danych, ponieważ już posiada inode.

Aplikacje często tłumaczą błąd alokacji na ogólny komunikat „Brak miejsca na urządzeniu”. Ten komunikat wskazuje na nieudaną alokację zasobów, ale nie informuje użytkownika, czy brakujący zasób to bloki danych, inode, limit kwoty czy przestrzeń metadanych specyficzna dla systemu plików. Widoczny błąd musi być powiązany z licznikami systemu plików.

Które obciążenia domowego NAS generują ekstremalną liczbę plików

Ryzykowne obciążenie to nie tylko „duże dane”. To każde obciążenie, które materializuje wiele niezależnych obiektów systemu plików, zwłaszcza gdy czyszczenie lub retencja pozwala tym obiektom gromadzić się przez miesiące.

Warstwy kontenerów, logi i drzewa pakietów

Obrazy kontenerów, wyodrębnione pakiety oprogramowania, drzewa zależności, rotujące logi i pamięci podręczne aplikacji mogą umieszczać dużą liczbę małych obiektów pod jedną usługą hostowaną na NAS. Obraz kontenera może wydawać się niewielki w gigabajtach, podczas gdy jego rozpakowane warstwy i stan zapisu zużywają znacznie więcej tożsamości obiektów niż plik multimedialny o tym samym rozmiarze.

Miniatury zdjęć i indeksy wyszukiwania

Menadżer zdjęć może generować miniatury, podglądy, pliki towarzyszące, wycinki twarzy lub fragmenty indeksu dla każdego źródłowego zasobu. Niektóre aplikacje konsolidują te rekordy w bazach danych, podczas gdy inne przechowują wiele z nich jako zwykłe pliki, więc efekt inode zależy od projektu przechowywania aplikacji, a nie tylko od rozmiaru biblioteki zdjęć.

Synchronizacja historii, drzew kopii zapasowych i magazynów poczty

Systemy wersjonowania, które materializują rewizje jako pliki, drzewa kopii zapasowych zawierające wiele obiektów źródłowych oraz skrzynki pocztowe z jednym komunikatem na plik mogą generować dużą liczbę plików. Migawki copy-on-write i zduplikowane repozytoria mogą reprezentować wersje inaczej, więc liczba migawek nie powinna być traktowana jako bezpośrednia liczba inode'ów bez sprawdzenia implementacji.

Dlaczego pulpit pojemności może nie wykryć presji inode'ów

Wiele pulpitów nawigacyjnych podkreśla bajty: całkowitą pojemność, użyte bloki i wolne bloki. Standardowy interfejs statystyk systemu plików przechowuje liczniki obiektów oddzielnie jako całkowitą, wolną i dostępną liczbę plików; na Linuksie odpowiadają temu pola takie jak f_files i f_ffree w statvfs statystykach systemu plików. Interfejs użytkownika pomijający te pola może wyglądać na zdrowy podczas klasycznego wyczerpania inode'ów.

Na NAS opartym na Linuksie z dostępem do powłoki można porównać użycie bloków i inode'ów dla tej samej zamontowanej ścieżki:

df -h /ścieżka/na/nas  
df -i /ścieżka/na/nas  

Podręcznik GNU df definiuje -i jako użycie inode'ów zamiast bloków i pokazuje pola całkowite, użyte, dostępne oraz procentowe. Wolne bloki przy zerowej liczbie dostępnych inode'ów zdecydowanie wskazują na klasyczne wyczerpanie inode'ów; zapas w obu kolumnach wskazuje na inny limit.

Systemy plików z inode'ami stałymi i dynamicznymi zawodzą inaczej

„NAS skończył się na inode'ach” jest prawdziwe tylko wtedy, gdy model alokacji systemu plików i zgłaszane liczniki to potwierdzają. Ten sam komunikat o braku miejsca może pochodzić z innej granicy metadanych w innym systemie plików.

Polityka przestrzeni inode XFS może ograniczać procent systemu plików przydzielony inode’om, podczas gdy oficjalne raportowanie systemu plików Btrfs rozdziela Dane, System, Metadane i GlobalReserve. Te modele mogą generować ograniczenia związane z metadanymi, ale nie powinno się ich tłumaczyć tak, jakby każdy NAS miał tę samą stałą tabelę inode’ów.

Ogólny interfejs statystyk ostrzega również, że nie każde zwrócone pole ma znaczenie na każdym systemie plików. Najpierw zidentyfikuj zamontowany system plików, a następnie interpretuj df -i poprzez tę implementację zamiast traktować jedno polecenie jako uniwersalny dowód.

Co oznacza rezerwa inode’ów dla planowania pojemności NAS

Prognoza pojemności dla obciążenia z dużą liczbą obiektów wymaga zarówno oczekiwanej liczby bajtów, jak i oczekiwanej liczby obiektów. Archiwa multimedialne zwykle są gęste pod względem bajtów, podczas gdy drzewa zależności, miniatury, magazyny poczty i zmaterializowane drzewa kopii zapasowych mogą być gęste pod względem obiektów. Dwa obciążenia o tym samym rozmiarze logicznym mogą więc wymagać bardzo różnej rezerwy metadanych.

Dla woluminu ext4 stosunek bajtów na inode jest wyborem projektowym podczas formatowania, a nie normalnym parametrem do regulacji w trakcie pracy. Zmiana rozmiaru może dodać inode’y zgodnie z ustalonym stosunkiem, ale nie zmienia go wstecznie na gęstszy. Ponowne formatowanie wyłącznie w celu zmiany tego stosunku to decyzja migracyjna z konsekwencjami tworzenia kopii zapasowych i przywracania, a nie zwykła poprawka wydajności.

Gdy presja na inode’y zostanie wykluczona, pozostają zwykłe pytania o pojemność bloków; plan pojemności pamięci NAS w domu może uzupełnić tę decyzję, ale wskazówki dotyczące wolnych terabajtów nie zastępują liczenia inode’ów ani metadanych.

Dlaczego usunięcie jednego dużego pliku może nie zwolnić wystarczającej liczby inode’ów

Usunięcie jednego dużego filmu może zwolnić wiele bloków danych, ale zazwyczaj zwalnia tylko jeden inode. Usunięcie drzewa katalogów zawierającego setki tysięcy zbędnych obiektów cache może zwolnić wiele inode’ów, nawet gdy odzyskana pojemność w bajtach jest stosunkowo niewielka. Czyszczenie musi odpowiadać wyczerpanemu zasobowi.

Obiekt odłączony nie jest zawsze natychmiast zwalniany. Zachowanie unlink w Linux utrzymuje plik w istnieniu, gdy proces nadal ma otwarte jego ostatnie dowiązanie, i zwalnia go po zamknięciu ostatniego odnoszącego się deskryptora pliku. Odzyskiwanie inode może więc opóźniać się względem usunięcia ścieżki dla aktywnych logów lub plików usługowych.

FAQ

Czy każdy plik używa dokładnie jednego inode?

Zwykły plik ma zazwyczaj jeden inode, a katalogi i dowiązania symboliczne również mają własne tożsamości systemu plików. Wiele nazw dowiązań twardych może wskazywać na ten sam inode, podczas gdy funkcje specyficzne dla systemu plików mogą przechowywać dodatkowe metadane w oddzielnych obiektach, więc liczba ścieżek i liczba inode są powiązane, ale nie zawsze identyczne.

Czy pamięć podręczna SSD lub szybsza sieć mogą zapobiec wyczerpaniu inode?

Nie. Szybsze nośniki i sieci mogą zmniejszyć opóźnienia lub zwiększyć przepustowość, ale nie tworzą dodatkowych slotów inode w stałej populacji inode. Mogą sprawić, że obciążenie z dużą liczbą plików zakończy się szybciej i szybciej osiągnie ten sam limit metadanych.

Czy df -i działa na każdym systemie plików domowego NAS?

Raportuje liczniki w stylu inode dostarczane przez zamontowany interfejs systemu plików, ale te liczniki mogą nie mieć takiego samego znaczenia w każdym systemie plików. Używaj ich bezpośrednio do diagnozy w stylu ext4 i łącz z narzędziami specyficznymi dla systemu plików dla XFS, Btrfs, ZFS lub urządzenia, które abstrahuje podległy wolumen.

Czy rozszerzenie systemu plików ext4 może dodać więcej inode?

Tak, zmiana rozmiaru ext4 może dodać inode podczas dodawania nowej przestrzeni, zachowując istniejący stosunek bajtów do inode. Różni się to od zmiany tego stosunku w istniejącym systemie plików, co według dokumentacji narzędzia do tworzenia nie jest obsługiwane po sformatowaniu.

Czy każdy błąd „Brak miejsca na urządzeniu” jest spowodowany inode?

Nie. Pełne bloki danych, limity kwot, zarezerwowane miejsce, alokacja metadanych Btrfs, limity przestrzeni tymczasowej oraz niektóre ograniczenia zasobów innych niż pamięć masowa mogą generować podobne komunikaty. Wyczerpanie inode jest obsługiwane, gdy błąd dotyczy tworzenia obiektów systemu plików, a odpowiedni licznik inode nie ma dostępnych wpisów.

Liczba plików to odrębny wymiar pojemności

Domowy NAS może zachować wolne miejsce na dysku, a jednocześnie przestać akceptować nowe obiekty, ponieważ bajty i metadane systemu plików to oddzielne wymiary pojemności. Traktuj dużą liczbę plików jako właściwość obciążenia, potwierdź faktyczny system plików i porównaj zapas bloków z zapasem inode lub metadanych, zanim stwierdzisz, że dyski są pełne.