O tak. Wykonując polecenie ln -s
, tworzysz dowiązanie symboliczne, które jest i- węzłem wskazującym na określony obiekt systemu plików, dlatego dowiązania symboliczne mogą przechodzić przez systemy plików, a dowiązania twarde nie mogą: dowiązania twarde nie mają własnego i-węzła.
Jeśli montujesz system plików --bind
, tworzysz drugi punkt montowania dla urządzenia lub systemu plików.
Jeśli wyobrażasz sobie dowiązanie symboliczne jako przekierowanie, to wyobraź sobie --bind
zamontowany system plików jako kolejną bramę do danych.
Łącza symboliczne i łączenie opraw to zupełnie inna gra.
--bind
Mocowanie wydaje się nieco bardziej odporne na mnie i to prawdopodobnie jest nieco szybciej niż praca z dowiązania symbolicznego. Z drugiej strony nie ma poważnych wad korzystania z dowiązania symbolicznego, ponieważ wydajność będzie niewielka (jeśli w ogóle istnieje).
Edycja : Myślałem o tym, a wydajność może być nieco większa, niż początkowo myślałem. Jeśli masz aplikację, która odczytuje wiele różnych plików, każdy nowy plik, który zostanie otwarty, będzie wymagał dodatkowego odczytu. Niektóre badania tutaj sugerują, że moje założenie jest poprawne, więc jeśli masz tam ciężką aplikację IO, rozważ --bind
opcję zamontowania nad rozwiązaniem dowiązania symbolicznego.
Powodem, dla którego nie jest to powszechne, jest prawdopodobnie fakt, że dowiązanie symboliczne jest widoczne w ls
, podczas gdy łączenie łączenia jest widoczne tylko podczas patrzenia na / proc / mounts lub / etc / mtab (co robi polecenie mount, jeśli jest wykonywane bez parametrów). Poza tym nie sądzę, żeby były jakieś problemy. Byłbym jednak zainteresowany, gdyby tak było.
Dodanie : innym problemem ln -s
jest to, że w przypadku niektórych aplikacji, gdy ścieżka zostaje zaniedbana, może to powodować zawieszanie się aplikacji, jeśli „spodziewa się”, że niektóre elementy znajdują się w określonych miejscach.