Dlaczego specjalne pliki urządzeń mają i-węzły?


11

Pliki urządzeń nie są plikami jako takimi. Są interfejsem we / wy do używania urządzeń w systemach operacyjnych typu Unix. Nie używają miejsca na dysku, jednak nadal używają i-węzła, jak podano w statpoleceniu:

$ stat /dev/sda
      File: /dev/sda
      Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 6h/6d   Inode: 14628       Links: 1     Device type: 8,0

Czy pliki urządzeń używają fizycznych i- węzłów w systemie plików i dlaczego w ogóle ich potrzebują?


2
I-węzeł i dane plikiem. Bez i-węzła nie masz pliku. (Pliki urządzeń nie zawierają żadnych danych)
user253751

Odpowiedzi:


16

Krótka odpowiedź brzmi, że dzieje się tak tylko wtedy, gdy masz fizyczne wsparcie systemu plików /dev(a jeśli używasz nowoczesnej dystrybucji Linuksa, prawdopodobnie nie masz).

Długa odpowiedź brzmi:

Wszystko to wraca do pierwotnej filozofii UNIX, że wszystko jest plikiem. Ta filozofia jest częścią tego, co sprawiło, że UNIX jest tak wszechstronny, ponieważ można bezpośrednio wchodzić w interakcje z urządzeniami z przestrzeni użytkownika bez konieczności posiadania specjalnego kodu w aplikacji, aby rozmawiać bezpośrednio ze sprzętem fizycznym.

Pierwotnie /devbył to po prostu inny katalog o znanej nazwie, w którym umieszczasz pliki urządzenia. Niektóre systemy UNIX nadal przyjmują takie podejście (uważam, że OpenBSD nadal tak robi) i zazwyczaj można stwierdzić, czy system taki jest, ponieważ będzie miał wiele plików urządzeń dla urządzeń, których system w rzeczywistości nie ma (na przykład pliki dla każdego możliwa partycja na każdym możliwym dysku). Oszczędza to miejsce w pamięci i czas przy rozruchu kosztem użycia nieco więcej miejsca na dysku, co było dobrym kompromisem dla wczesnych systemów, ponieważ były one na ogół bardzo ograniczone w pamięci i niezbyt szybkie. Jest to ogólnie nazywane statycznym /dev.

W nowoczesnych systemach Linux (i uważam również, że FreeBSD i prawdopodobnie najnowsze wersje Solaris), /devto tymczasowy system plików w pamięci zapełniany przez jądro (lub udev, jeśli używasz Systemd, ponieważ nie ufają jądru, że zrobi prawie wszystko) . Oszczędza to miejsce na dysku w cenie pewnej pamięci (zwykle mniej niż kilka MB) i bardzo mały narzut przetwarzania. Ma również szereg innych zalet, z których jedną z największych jest to, że łatwiej jest wykryć sprzęt podłączony na gorąco. Jest to ogólnie określane jako dynamiczne /dev.

W obu przypadkach dostęp do węzłów urządzeń jest uzyskiwany za pośrednictwem zwykłej warstwy VFS, co z definicji oznacza, że ​​muszą one mieć i-węzeł (nawet jeśli jest to wirtualny, który istnieje, aby rzeczy takie stat()jak powinny. Z praktycznego punktu widzenia ma to zerowy wpływ na systemy, które używają dynamiki, /devponieważ tylko przechowują i-węzły w pamięci lub generują je w razie potrzeby, i prawie zerowy wpływ tam, gdzie /devjest statyczny, ponieważ i-węzły zajmują prawie zerową przestrzeń na dysku, a większość systemów plików nie ma górnego limitu lub zapewnić znacznie więcej niż ktokolwiek może kiedykolwiek potrzebować.


3
Ostrożnie podnosi rękę. Byłem przy projekcie, w którym na serwerze zabrakło i-węzłów. W końcu był to kryzys, który nasz zespół musiał przekonać kierownictwo do zainwestowania w wymianę tego systemu zaplecza, który został zaprojektowany (źle, jak można sobie wyobrazić!), Zanim ktokolwiek z nas tam dotarł.
KRyan,

@KRyan Może się zdarzyć, ale obecnie zdarza się to rzadko, chyba że administrator wyraźnie ograniczył liczbę przy tworzeniu systemu plików. Wiele współczesnych systemów plików (przynajmniej NTFS, BTRFS i ZFS, myślę, że XFS też) może faktycznie alokować i-węzły dynamicznie, więc na wielu nowszych systemach tak naprawdę nie można go zabraknąć.
Austin Hemmelgarn,

@ KR Ryan Ja też miałem ten problem. I to był właściwie dobrze zaprojektowany system, choć nieco przestarzały i zabrany do ekstreamów (każda transakcja wymagała niezależnego dziennika, który był przechowywany na dysku, w końcu po prostu zapełnił się małymi małymi i
węzłami

1
Od i doker jest znany jako powodujący dokładnie ten problem z węzłem.
coteyr

@AustinHemmelgarn Rodzina ext jest raczej niesławna ze względu na statyczną liczbę i-węzłów (a następnie ich brak). Jest to, nawiasem mówiąc, najczęściej używany system plików Linuksa, prawdopodobnie z ogromnym marginesem (scenariusze przechowujące duże ilości danych na bokach XFS, przy czym ZFS i BTRFS są stosunkowo nowe), i domyślny dla większości dystrybucji. Oczywiście w nowoczesnym systemie domyślne maksymalne i-węzły są o wiele rzędów wielkości większe niż liczba plików urządzeń, jakie kiedykolwiek będziesz mieć.
Bob

15

Pliki urządzeń również mają uprawnienia, które są przechowywane w i-węzle.


Znakomity punkt, o którym zapomniałem wspomnieć.
Austin Hemmelgarn,

5
Nie tylko uprawnienia, ale także typ pliku i inne metadane. Klasycznie sam katalog zawiera tylko nazwę i numer i-węzła - nic nie wskazuje na to, że plik jest urządzeniem, dopóki nie przeczytasz i-węzła.
Gilles 'SO - przestań być zły'

12

Katalogi są po prostu odwzorowaniem nazw plików na i-węzły, więc wszystko, czego dotyczy nazwa (plik, dowiązanie symboliczne, urządzenie, FIFO, gniazdo), musi znajdować się w i-węźle, nie ma gdzie indziej.

Informacje o urządzeniu są przechowywane w i-węźle. Główne i drobne numery urządzeń są tam, podobnie jak uprawnienia, znaczniki czasu itp. Pole typu, które mówi, że jest to urządzenie blokowe lub znakowe, a nie zwykły plik, jest tam przechowywane.

I-węzeł dla urządzeń po prostu nie korzysta z pól zawierających mapę blokową pliku.


0

Bez i-węzła miałabyś tylko nazwę pliku, która przechowywałaby wszystkie informacje o danym urządzeniu. Oznacza to, że „ładne” nazwy urządzeń, takie jak, /dev/sdabyłyby wykluczone: potrzebujesz nazwy, która mogłaby być powiązana z określonym sterownikiem, np /dev/ohci/sda.

Co ważniejsze, wszystkie narzędzia, które polegają na węzłów (jak stat, lsi tak dalej) musiałyby być modyfikowane pod traktować ścieżek /devw sposób szczególny. Byłoby to zbyt duże nakłady pracy bez widocznych korzyści w porównaniu z obecnym stanem rzeczy.

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.