Jaka jest różnica między „rozmiarem i-węzła” a „Bajtami na i-węzeł”

Poniższe informacje pochodzą ze strony podręcznika. Chciałbym poznać różnicę między bajtami na-i-węzłem a rozmiarem-i-węzła?

-i bytes-per-inode

Określ stosunek bajtów / i-węzłów. mke2fs tworzy i-węzeł dla każdego bajtu na bajt miejsca na dysku. Im większy stosunek bajtów do i-węzłów, tym mniej powstanie i-węzłów. Wartość ta zasadniczo nie powinna być mniejsza niż rozmiar bloku systemu plików, ponieważ wtedy powstanie zbyt wiele i-węzłów. Ostrzegamy, że nie jest możliwe zwiększenie liczby i-węzłów w systemie plików po jego utworzeniu, więc uważaj, wybierając właściwą wartość tego parametru.

-I inode-size

Określ rozmiar każdego i-węzła w bytes.mke2fs domyślnie tworzy 256-bajtowe i-węzły. W jądrach po wersji 2.6.10 i niektórych wcześniejszych wersjach jądra można wykorzystywać i-węzły większe niż 128 bajtów do przechowywania rozszerzonych atrybutów w celu poprawy wydajności. Wartość wielkości i-węzła musi wynosić 2 lub więcej lub 128. Większy i-węzeł -rozmiar, tym więcej miejsca zajmie tabela i-węzłów, co zmniejszy powierzchnię użytkową w systemie plików i może również negatywnie wpłynąć na wydajność. Rozszerzone atrybuty przechowywane w dużych i-węzłach nie są widoczne w starszych jądrach, a takich systemów plików nie można zamontować w jądrach 2.4 w ogóle. Nie można zmienić tej wartości po utworzeniu systemu plików.

Po pierwsze, czym jest i-węzeł? W świecie uniksowym i-węzeł jest rodzajem wpisu pliku. Nazwa pliku w katalogu to tylko etykieta (link!) Do i-węzła. Do i-węzła można się odwoływać w wielu lokalizacjach (hardlinks!).

-i bajty-na-i-węzeł (aka inode_ratio)

Z nieznanych przyczyn ten parametr jest czasami dokumentowany jako bajty na i-węzeł, a czasami jako inode_ratio . Zgodnie z dokumentacją jest to stosunek bajtów do i-węzłów . Większość ludzi będzie lepiej rozumiała, jeśli zostanie podana jako jedna z nich (przepraszam za angielski):

• 1 i-węzeł na każde X bajtów pamięci (gdzie X to bajty na i-węzeł).
• najniższy średni rozmiar plików, jaki możesz zmieścić.

Formuła (wzięta z mke2fs kodu źródłowego ):

inode_count = (blocks_count * blocksize) / inode_ratio

Lub nawet uproszczony (zakładając, że „rozmiar partycji” jest mniej więcej równoważny blocks_count * blocksize, nie sprawdziłem alokacji):

inode_count = (partition_size_in_bytes) / inode_ratio

Uwaga 1: Nawet jeśli podasz stałą liczbę i-węzłów w czasie tworzenia FS ( mkfs -N ...), wartość jest konwertowana na współczynnik, dzięki czemu możesz zmieścić więcej i-węzłów, gdy zwiększasz rozmiar systemu plików.

Uwaga 2: Jeśli dostosujesz ten współczynnik, pamiętaj, aby przydzielić znacznie więcej i-węzłów niż to, co planujesz użyć ... naprawdę nie chcesz ponownie formatować systemu plików.

-I rozmiar i-węzła

Jest to liczba bajtów, które system plików przydzieli / zarezerwuje dla każdego i-węzła, jaki może mieć system plików. Spacja służy do przechowywania atrybutów i-węzła (czytaj Wprowadzenie do i-węzłów ). W Ext3 domyślny rozmiar wynosił 128. W Ext4 domyślny rozmiar to 256 (do przechowywania extra_isizei zapewnienia miejsca na wbudowane atrybuty rozszerzone). przeczytaj Linux: Po co zmieniać rozmiar i-węzła?

Uwaga: X bajtów przestrzeni dyskowej jest przydzielanych dla każdego przydzielonego i-węzła, zarówno wolnego, jak i używanego, gdzie X = rozmiar i-węzła.

bytes-per-i-węzeł określa liczbę i-węzłów tworzonych dla tego systemu plików; rozmiar i-węzła określa, jak duży jest każdy z tych i-węzłów.

Potrzebujesz dużo i-węzłów, jeśli zamierzasz umieścić wiele małych plików (i / lub wiele katalogów) w tym pliku.

AFAIK, tak naprawdę potrzebujesz tylko i-węzłów, które są większe niż domyślny rozmiar 256 bajtów, jeśli chcesz przechowywać rozszerzone atrybuty plików. psusi mówi w komentarzach, że to nie jest poprawne.

Niezwykle szorstki schemat systemu plików:

|_|__inodes__|_______________________DATA_________________________________|

• iwęzeł przełożeniem / bajty-per-węzeł = ilości węzłów dla DATA dziedzinie
• iwęzeł wielkości = rozmiar każdego węzła w inodes dziedzinie

Naprawdę podobała mi się odpowiedź sjas, daje ona istotę różnicy.

To jest tylko moje własne rozszerzenie (ponieważ nie mogę komentować ani głosować, zaczynając od tej wymiany stosów) i chciałem znaleźć odpowiedź na siebie w sposób zrównoważony w nietechnicznych terminach zrozumiały dla użytkownika, który musi podjąć decyzję w sprawie ilości danych konfiguracji, ale niekoniecznie znać wszystkie szczegóły związane z implementacją.

Personas / Objects: - woluminy danych w urządzeniach pamięci - pliki w woluminach - urządzenia pamięci, są one sformatowane i zapewniają bloki bajtów i ich adresy - lokalizacje plików w pamięci

Działania: tworzenie / usuwanie / zmiana nazw plików i folderów przez system operacyjny w pamięci, odczytywanie / zapisywanie / przenoszenie plików, zmiany uprawnień itp.

Plik o wielkości N bajtów należy utworzyć w „porcjach” (blokach). Chociaż teoretycznie można pomyśleć, że plikami można zarządzać jako sekwencjami pojedynczych bajtów (logicznie mogą), wszystkim, czego potrzebowalibyśmy do zarządzania plikami w przestrzeni, byłby wyznaczony indeks informujący o niektórych właściwościach plików (nazwa itp.) I gdzie każdy plik zaczyna się w magazyn. Jednak ze względu na sposób zaprojektowania sprzętu z „magistralami” i „blokami” oraz względy wydajnościowe te „fragmenty” mają określony rozmiar i wielokrotność rozmiaru bloku nośnika (np. 512 bajtów, 4096 bajtów) i są zarządzany przez warstwę i-węzłów, która informuje następną warstwę o lokalizacjach plików i sposobie łączenia fragmentów, gdy trzeba je znaleźć, załadować do pamięci itp.

Jeśli ktoś miał jeden duży zwój papieru (wolumin) i musiał zaprojektować miejsce do przechowywania informacji dla dokumentów złożonych ze stron (znaków lub fragmentów informacji) do przechowywania dokumentów wielostronicowych, potrzebny jest indeks (do znalezienia dokumentów), miejsce do przechowywania strony (z kilkoma prostymi pozycjami stron). W unikatowym mechanizmie sortowania (i-węzłach) i rzeczywistym cięciu na strony. inode-size to rozmiar pozycji indeksu (mniej więcej) bajty na i-węzeł to rozmiar strony

Skutki zmiany tych dwóch ustawień:

zmiana rozmiaru i-węzła - zwykle nie ma potrzeby zmiany, trzymaj się wartości domyślnej (zgodnie z linkiem zamieszczonym w poprzedniej odpowiedzi do dyskusji)

bytes-per-i-inode - wpływa na maksymalną liczbę plików, jakie można utworzyć w woluminie (możliwa wydajność i „marnotrawstwo” nieużywanych bajtów)

Wracając do analogii rolek papieru: Wyobraź sobie, że musisz napisać i przechowywać dokument o określonym rozmiarze (plik) w takim systemie (lub wiele dokumentów o różnych rozmiarach) - jeśli rozmiar strony jest ustalany podczas „systemu zapisu i przechowywania” „definicja i brak elastyczności” oznacza, że ​​ten sam dokument może wymagać wielu stron, jeśli rozmiar strony „systemowej” jest bardzo duży, a rozmiar dokumentu niewielki, wówczas dużo papieru może zostać zmarnowane przez puste miejsca i dopasowanie małych plików na jednej stronie. Jeśli rozmiar strony jest duży - jest mniej stron, które trzeba użyć w dokumencie, ale na ostatniej użytej stronie może być dużo „zmarnowanej pustej przestrzeni”. Wszystko zależy więc od wielkości plików, które będą używane i od ich liczby. Innym czynnikiem jest szybkość znajdowania i przenoszenia dokumentu z wielu stron.

Mam nadzieję, że to ma sens (robi to dla mnie) i proszę o komentarz, jeśli poważnie nadużyłem jakiejkolwiek części opcji ext design lub mkfs.