Dlaczego twarde linki są ważne tylko w tym samym systemie plików?

22

Czytam to wprowadzenie do wiersza poleceń Marka Batesa.

W pierwszym rozdziale wspomina, że ​​twarde łącza nie mogą obejmować systemów plików.

Ważną rzeczą do zapamiętania na temat twardych linków jest to, że działają one tylko w bieżącym systemie plików. Nie można utworzyć twardego łącza do pliku w innym systemie plików. Aby to zrobić, musisz użyć dowiązań symbolicznych, Rozdział 1.4.3.

Znam tylko jeden system plików. Ten zaczynający się od root ( /). To stwierdzenie, że twarde linki nie mogą obejmować wielu systemów plików, nie ma dla mnie sensu.

Artykuł Wikipedii na temat systemów plików Unix również nie jest pomocny.

Anton Paras
źródło

Odpowiedzi:

29

Mam nadzieję, że mogę odpowiedzieć na to w sposób, który ma dla ciebie sens. System plików w Linuksie zazwyczaj składa się z partycji sformatowanej na jeden z różnych sposobów (musisz kochać wybór!), Na której przechowujesz swoje pliki. Czy to pliki systemowe, czy pliki osobiste ... wszystkie są przechowywane w systemie plików. Ta część wydaje się rozumieć.

Ale co, jeśli podzielisz dysk twardy na partycje, aby mieć więcej niż jedną partycję (uważasz, że Apple Pie jest podzielony na kawałki), lub dodasz dodatkowy dysk twardy (być może pamięć USB?). Ze względu na argumenty wszystkie mają również systemy plików.

Kiedy patrzysz na pliki na swoim komputerze, widzisz wizualną reprezentację danych w systemie plików partycji. Każda nazwa pliku odpowiada tak zwanemu i-węzłowi, czyli miejscu, w którym naprawdę żyją twoje dane za kulisami. Twardy link pozwala na posiadanie wielu „nazw plików” (z braku lepszego opisu), które wskazują na ten sam i-węzeł. Działa to tylko wtedy, gdy te twarde łącza znajdują się w tym samym systemie plików. Łącze symboliczne wskazuje natomiast na „nazwę pliku”, która następnie jest połączona z i-węzłem przechowującym twoje dane. Wybacz moje prymitywne dzieła sztuki, ale mam nadzieję, że to wyjaśnia lepiej.

image.jpg             image2.jpg
          \           /
           [your data]

zarówno image.jpg, jak i image2.jpg wskazują bezpośrednio na twoje dane. Oba są linkami twardymi. Jednak...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

W tym (surowym) przykładzie image2.jpg nie wskazuje na twoje dane, wskazuje na image.jpg ... który jest linkiem do twoich danych.

Dowiązania symboliczne mogą działać ponad granicami systemu plików (zakładając, że system plików jest podłączony i zamontowany, podobnie jak pamięć USB). Jednak twardy link nie może. Nic nie wie o tym, co znajduje się w innym systemie plików lub gdzie są przechowywane dane.

Mam nadzieję, że to pomoże lepiej zrozumieć.

dubkat
źródło
Dzięki. Nie wiedziałem, że różne partycje plików nazywane są „systemami plików”.
Anton Paras,
1
jedną z rzeczy, które możesz zrobić z partycją, jest umieszczenie na niej systemu plików, istnieją inne miejsca, w których możesz umieścić systemy plików i inne rzeczy, które możesz zrobić z partycjami, ale najczęstszą opcją jest ta.
Jasen
10
Istnieje jedna hierarchia plików, która zaczyna się od „/”. Będzie miał zainstalowany jeden lub więcej systemów plików
mpez0
@ mpez0: Nawet nie, przy np. chroot(2)prawdziwej konteneryzacji możesz mieć wiele hierarchii, które mogą nie mieć ze sobą nic wspólnego.
Kevin
@Kevin chrootizoluje część hierarchii dla procesu i jego potomków, ale rodzic nadal ma jednego kompletnego hierarchię. Konteneryzacja może to zrobić, w zależności od tego, jak blisko jest maszyny wirtualnej. Ale ile szczegółów można spakować w komentarz? Dzięki,
mpez0,
23

System plików składa się ze struktury katalogów złożonych z pozycji katalogu w celu organizowania plików. Każda pozycja katalogu wiąże nazwę pliku z i- węzłem .

Miękkie łącza ( symboliczne ) to wpisy do katalogu, które nie zawierają danych, wskazują tylko na inny wpis (plik lub katalog w tym samym systemie plików lub innym systemie plików). A po usunięciu wskazanego pliku łącze symboliczne staje się bezużyteczne.

Twarde linki to pozycja katalogu, która zawiera nazwę pliku i numer i- węzła . Po usunięciu ostatniego twardego łącza nie można uzyskać dostępu do pliku.

Różnica między miękkim łączem a twardym łączem

Wniosek:

Ponieważ i- węzeł jest strukturą danych używaną do reprezentowania obiektu systemu plików, jest on wewnętrzny w systemie plików i nie można wskazać i- węzła innego systemu plików.

Tak więc dowiązania twarde są prawidłowe tylko w tym samym systemie plików, ale dowiązania miękkie (dowiązanie symboliczne) mogą obejmować systemy plików, ponieważ po prostu wskazują na inną pozycję katalogu (interfejs systemu plików, a nie obiekt wewnętrzny).

Facundo Victor
źródło
1
Ładna, zwięzła odpowiedź.
dubkat
Co się stanie, jeśli inny system plików (powiedzmy USB) będzie miał plik o tej samej NAZWIE, do którego nasz symboliczny link jest podłączony w naszym systemie plików?
Josef Klimuk
@JosefKlimuk, powiedzmy, miękki link wskazywałby na ścieżkę /mnt/myfile. Jeśli podłączysz do innego systemu plików /mnt/. Miękki link zostałby rozwiązany w pozycji zamontowanego systemu plików pod /mnt/. Tak więc, jeśli podłączyłeś system plików z urządzenia USB /mnt, miękkie łącze przekształciłoby się w pozycję w tym systemie plików.
Facundo Victor
2

Główny system plików może składać się z kilku systemów plików; /usr/localmoże być zamontowany na osobnej partycji i /homemoże znajdować się na innej partycji na dysku sieciowym w innym miejscu. W takim przypadku /usr/local/bin/gitnie można utworzyć twardego łącza dla (na przykład) poza /usr/local, ponieważ obejmowałby on systemy plików .

Powodem tego jest to, że węzły są przydzielane oddzielnie /, /usr/locali /home(ponownie, w tym przykładzie), a po utworzeniu łącza naprawdę po prostu zrobić dodatkową nazwę dla węzła.

Kusalananda
źródło
2

Twarde linki powodują, że cel pozostaje przy życiu. Tak długo, jak dostępne jest twarde łącze, system dopilnuje, aby jego cel nie został zwolniony. Dlatego konieczne jest, aby wszystkie media, które mogłyby zawierać twarde linki do konkretnego i-węzła, były montowane za każdym razem, gdy system próbowałby ustalić, czy istnieją jakieś odniesienia do niego.

Biorąc pod uwagę, że czas życia i-węzła jest zwykle określany przez utrzymywanie liczby referencji zamiast skanowania referencji, może być możliwe zaaranżowanie rzeczy w taki sposób, że dwa lub więcej systemów plików, które przechowują linki do siebie, mogą być używane niezależnie, pod warunkiem, że nie ma potrzeby korzystania z łączy, które połączony między systemami i pod warunkiem, że nie będzie potrzeby używania fsck na żadnym z nich. Jeśli jednak inode liczy się, że jeden z systemów zostanie zakłócony, jedynym sposobem, aby ten system znów był użyteczny, byłoby użycie formy operacji fsck, która mogłaby skanować oba systemy plików w poszukiwaniu referencji. Z powodu tego ograniczenia, chociaż może być możliwe zezwolenie na niezależne używanie dwóch połączonych systemów plików, korzyści wynikające z takiego postępowania byłyby prawdopodobnie zbyt ograniczone, aby było warto.

supercat
źródło
Dobra uwaga, ale nieco zbyt styczna, aby być dobrą odpowiedzią.
Joe
@Joe: Zezwolenie na tworzenie twardych linków do różnych systemów plików spowodowałoby szereg trudności technicznych, ale większość z nich można przezwyciężyć, podnosząc w ten sposób pytanie, czy istnieje jakiś istotny powód, dla którego nie powinny . Problem utrzymywania się przy życiu może wydawać się niejasny, ale w przeciwieństwie do innych problemów, mogę go rozwiązać tylko poprzez nałożenie poważnych ograniczeń semantycznych na użycie takich łączy, które poważnie ograniczyłyby ich wartość.
supercat
Słuszna uwaga. System plików można zamontować na innym urządzeniu i zmodyfikować, aby i-węzeł i łącza mogły zostać „zsynchronizowane”. Każdy system plików może mieć identyfikator GUID, a łącze może zawierać ten identyfikator GUID, aby śledzić i-węzeł w różnych systemach plików. Na FS może być również jakiś dziennik, a następnie, gdy jest on zamontowany, system hosta nie musiałby go skanować, ale mógł po prostu odczytać dziennik i „nadrobić” zmiany w łączeniu i-węzła (kiedy go wyczyścimy, chociaż?). Podsumowując, FS leżący u podstaw wymagałby modyfikacji w trywialny sposób i działałby tylko w kompatybilnych systemach plików.
Rolf
1

Pojedynczy numer i- węzła służy do reprezentowania pliku w każdym systemie plików. Wszystkie twarde linki oparte na numerze i-węzła. Link do systemu plików tutaj .

msc
źródło