Jak linux działa z dowiązaniami symbolicznymi?

11

Mam na myśli to, co się dzieje, gdy jakiś proces chce odczytać dowiązanie symboliczne? Co się dzieje, gdy coś zmienia dowiązanie symboliczne podczas procesu odczytu lub nawet zapisu?

Na przykład: Mam 2 ogromne, podobne pliki 100G /mnt/1i /mnt/2. /mnt/1jest dostępny za pośrednictwem dowiązania symbolicznego /home/user/file. Niektóre programy Azaczynają czytać /home/user/file. I po chwili coś zmienia link z /mnt/1na /mnt/2, ale Anadal czyta plik.

Czy program buforuje ścieżkę bezwzględną?

Czy zawiedzie i popełni błąd, ponieważ dowiązanie symboliczne zostało zmienione, czy będzie działało dobrze, jakby nic się nie stało?

Czy będzie inaczej, jeśli /home/user/filebędzie połączone z urządzeniem blokowym (na przykład 2 replikowane dyski iscsi)?

wysypka
źródło

Odpowiedzi:

9

Dowiązanie symboliczne wskazuje nazwę prawdziwego pliku (i- węzła ) w systemie plików. Kiedy system rozwiązuje to dowiązanie symboliczne w celu znalezienia rzeczywistego pliku i otwarcia go, znajduje i używa i-węzła pliku. W tym momencie ścieżka, którą podałeś do pliku, nie ma znaczenia. Czego system operacyjny nie buforuje, odczytuje z pliku przez swój i-węzeł. Mogę, jak rozumiem, rozpocząć czytanie pliku za pomocą twardego łącza i usunąć ten twardy link (o ile plik jest nadal połączony z innego miejsca) i nie powodowałoby to problemów, dopóki plik został rozwiązany ( nazwa ciągu-> i-węzeł).

Kevin
źródło
4
Możesz usunąć WSZYSTKIE linki do pliku i nadal go czytać, kiedy już go otworzysz. Dlatego możesz aktualizować pakiety bez ponownego uruchamiania systemu, tak jak w Windowsie; ponieważ możesz uruchomić plik wykonywalny programu, nawet jeśli jest uruchomiony.
psusi
1
@psusi Wiem, że dane i i-węzeł nadal tam są i po prostu już ich nie wskazałem, ale po usunięciu pliku system może zastąpić to miejsce na dysku, prawda? Jeśli więc plik jest zbyt duży, aby zmieścić się w pamięci podręcznej plików, tak jak w przypadku plików o pojemności 100 GB, co się stanie, jeśli część z nich zostanie zastąpiona przed dojściem do końca? Nie dotyczy to krytycznych plików systemowych, ponieważ są one ładowane do pamięci podręcznej i tam przechowywane, ale 100 GB jest na tyle duże, że myślę, że może to być problem.
Kevin
2
Kevin, pliki nie były usuwane z dysku aż do śmierci ostatniego procesu używającego pliku. Zawsze możesz znaleźć wszystkie aktualnie używane pliki w proc. Ale twoja odpowiedź wydaje się wyjaśniać moje pytanie. Dzięki.
pędzi
2
Ta odpowiedź pomija punkt krytyczny, że dowiązanie symboliczne zawiera nazwę pliku docelowego.
Keith Thompson,
6

Symboliczny link jest mały plik, który zawiera lokalizację (czyli ścieżka i nazwa pliku) pliku docelowego, z flagą w pozycji katalogu, wskazując, że jest to dowiązanie.

Po otwarciu dowiązania symbolicznego system operacyjny podąża za lokalizacją, aby znaleźć plik docelowy. Jeśli cel sam w sobie jest dowiązaniem symbolicznym, podąża również za swoją lokalizacją (1) (2), dopóki lokalizacja nie wskaże pliku, który nie jest dowiązaniem symbolicznym (nazwijmy go FinalFile ). Następnie OS uzyskuje iwęzeł z FinalFile (iwęzeł zawiera metadane, takie jak modyfikacja czasie i ma również wskaźnik do danych pliku,). W końcu otwiera się i- węzeł pliku końcowego . Od tej chwili proces używa tego i-węzła do odczytu / zapisu do pliku. W wyniku zmiany nazwy lub ścieżki dowiązania symbolicznego, usunięcia dowiązania symbolicznego, zmiany ścieżki lub nazwy pliku końcowego, a nawet usunięcia pliku końcowego(3) nie ma wpływu na proces; wciąż odczytuje z tego samego i-węzła.

W większości przypadków operacje na plikach danych na dowiązaniu symbolicznym będą miały wpływ na plik końcowy (np. Odczyt i zapis do pliku dowiązania symbolicznego zostanie odczytany z pliku / plik do pliku końcowego ), ale są wyjątki: readlink()wywołanie systemowe odczytuje zawartość samego dowiązania symbolicznego.

Z drugiej strony operacje na metadanych pliku (takie jak zmiana nazwy lub usuwanie) zwykle wpływają na dowiązanie symboliczne. Ale są też wyjątki: lstat()wywołanie systemowe jest podobne stat(), z tym wyjątkiem, że zwraca informacje o samym dowiązaniu symbolicznym, a nie o pliku końcowym (2).


(1) Istnieje ograniczenie liczby poziomów i sprawy stają się nieco bardziej złożone, jeśli lokalizacja w dowiązaniu symbolicznym jest ścieżką względną.

(2) Czytaj dowiązanie symboliczne (7): obsługa dowiązania symbolicznego, aby uzyskać więcej szczegółów.man 7 symlink

(3) rmPolecenie lub unlink()wywołanie systemowe nie usuwa fizycznie pliku. Usuwa pozycję katalogu wskazującą i-węzeł pliku. Sam plik jest usuwany tylko wtedy, gdy oba: a) nie ma już pozycji katalogu (dowiązań twardych), które odnoszą się do jego i-węzła ib) żaden proces nie otworzył pliku.

Keith Thompson
źródło
1

Jest to prawie przezroczyste dla Linuksa i jest znacznie bardziej związane z używanym systemem plików niż z systemem operacyjnym.

Nie jest to zwykły plik ani bardzo mały plik, ponieważ nie można utworzyć działającego dowiązania symbolicznego na partycji VFAT, na przykład po prostu kopiując do niego dowiązanie symboliczne, ponieważ jest ono rejestrowane bezpośrednio przez system plików.

Różnica w dowiązaniu symbolicznym do dowiązania twardego polega na tym, że spotkanie odbywa się na dowiązaniu twardym, a nie po przekierowaniu do sektorów danych, jak to robi łącze dowiązane.

Przykład:

Test 1:

echo 'data' >file.txt

Spowoduje to utworzenie twardego pliku link.txt wskazującego sektory od 10 do 20 * (* liczby tylko dla wyjaśnienia).

Test 2:

A co jeśli?

ln file.txt file_2.txt

To utworzyło hardlink file_2.txt wskazujący sektory od 10 do 20 (to samo co file.txt), więc jeśli usuniesz file.txt, sektory od 10 do 20 są nadal zarezerwowane i możesz zobaczyć dane w pliku file_2.txt ... . (zarówno plik.txt, jak i plik_2.txt są jak oryginały)

Test 3:

ln -s file.txt file_sym.txt 

Wskazał dowiązanie symboliczne file_sym.txt do twardego linku file.txt, więc kiedy spróbujesz uzyskać dostęp do file_sym.txt, zobaczysz file.txt, ale jeśli usuniesz file.txt file_sym nie znajdzie już celu.

Zarządza nimi system plików, na przykład moduły ext4 dla systemu Linux (lub jeśli jest on skompilowany w jądrze), nie ma znaczenia, czy używasz Linuksa czy innego Uniksa.

Luciano Andress Martini
źródło