Dlaczego montuje się w istniejącym katalogu?

Istniejący katalog jest potrzebny jako punkt podłączenia .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

Uważam to za mylące, ponieważ nakłada się na istniejącą zawartość katalogu. Istnieją dwie możliwe treści katalogu punktu podłączenia, które mogą zostać nieoczekiwanie przełączone (dla użytkownika, który nie wykonuje montowania).

Dlaczego nie mountdzieje się w nowo utworzonym katalogu? W ten sposób graficzne systemy operacyjne wyświetlają nośniki wymienne. Byłoby jasne, czy katalog jest podłączony (istnieje), czy nie został podłączony (nie istnieje). Jestem pewien, że istnieje dobry powód, ale jeszcze go nie odkryłem.

Jest to przypadek szczegółu implementacji, który wyciekł.

W systemie UNIX każdy katalog składa się z listy nazw odwzorowanych na numery i- węzłów . I-węzeł przechowuje metadane, które informują system, czy jest to plik, katalog, urządzenie specjalne, nazwany potok itp. Jeśli jest to plik lub katalog, informuje również system, gdzie znaleźć zawartość pliku lub katalogu na dysku. Większość i-węzłów to pliki lub katalogi. -iOpcja lsbędzie lista numerów węzłów.

Montowanie systemu plików zajmuje i-węzeł katalogu i ustawia flagę na kopii w pamięci jądra, aby powiedzieć „tak naprawdę, patrząc na zawartość tego katalogu, spójrz zamiast tego na inny system plików” (patrz slajd 10 tej prezentacji ). Jest to stosunkowo łatwe, ponieważ zmienia pojedynczy element danych.

Dlaczego zamiast tego nie tworzy pozycji katalogu wskazującej na nowy i-węzeł? Istnieją dwa sposoby, aby to zaimplementować, oba mają wady. Jednym z nich jest fizyczne zapisanie nowego katalogu w systemie plików - ale to się nie powiedzie, jeśli system plików jest tylko do odczytu! Drugim jest dodanie do każdego procesu wyświetlania katalogu listy „dodatkowych” rzeczy, których tak naprawdę nie ma. Jest to kłopotliwe i potencjalnie powoduje niewielki spadek wydajności przy każdej operacji na pliku.

Jeśli chcesz dynamicznie tworzone punkty montowania, automountsystem może to zrobić. Specjalne systemy plików inne niż dyskowe mogą również tworzyć katalogi na woli, na przykład proc, sys, devfsi tak dalej.

Edycja: zobacz także odpowiedź na Co się stanie, gdy „zamontujesz” istniejący folder z zawartością?

Jeśli mount(2) wymagane jest utworzenie nowego katalogu, który będzie punktem podłączenia, nie można zamontować niczego w systemie plików tylko do odczytu. To byłoby głupie, więc możemy to wykluczyć.

Gdyby mount opcjonalnie utworzył nowy katalog jako punkt podłączenia, byłoby to dziwne. Nie jest tak, że montowanie / odmontowywanie odbywa się cały czas, więc umieszczenie dodatkowej logiki w jądrze, aby wykonać te dwa kroki za pomocą jednego wywołania systemowego, nie byłoby ważnym przyspieszeniem. Wystarczy pozostawić przestrzeń użytkownika, aby wykonać mkdir(2)połączenie systemowe, jeśli chce. Odpowiedź Dmitry'ego wskazuje, że mount(2)zrobienie obu rzeczy sprawiłoby, że nie byłby to atom. A ty chcesz dodatkowy argument mount(2)z flagi trybu podoba open(2)trwa, dla O_CREAT, O_EXCLitp byłoby to po prostu głupie porównaniu do przestrzeni użytkownika pozwalając zrobić.

A może pytałeś o to, czy mount(8)(tradycyjny program, który wykonuje mount(2)wywołania systemowe) to robi? Byłoby to możliwe, ale już doskonale nadaje się mkdir(1)do tego zadania, a konstrukcja Uniksa polega na dobrych małych narzędziach, które można łączyć. Jeśli potrzebujesz narzędzia, które spełnia oba te warunki, łatwo jest napisać skrypt powłoki, aby zbudować to narzędzie z dwóch prostszych narzędzi. (Lub, jak skomentował Muru, udisksctljuż to robi, więc nie musisz tego pisać). Ponadto, normalny Linux mount(8)z util-linux obsługuje mount -o x-mount.mkdir[=mode]używanie jego x-składni dla opcji przestrzeni użytkownika, a nie opcji, które mają być przekazywane do systemu plików.

Teraz bardziej interesujące pytanie: dlaczego w ogóle nadrzędny system plików musi mieć katalog?

Jak wskazuje odpowiedź pjc50 (brak relacji, nawet jeśli ma moje inicjały!), Posiadanie punktów montowania wyświetlanych na listach katalogów wymagałoby wtedy dodatkowej kontroli każdego readdir().

Posiadanie punktów montowania, ponieważ katalogi w katalogu je zawierającym (na nadrzędnym FS) to niezła sztuczka. readdir()wcale nie musi zauważać, że jest to punkt montowania. Dzieje się tak tylko wtedy, gdy punkt montowania jest używany jako komponent ścieżki. Rozdzielczość ścieżki oczywiście musi sprawdzać tabelę montowania dla każdego elementu katalogu ścieżki.

Montowanie do istniejącego katalogu powoduje wywołanie mountpraktycznie atomowej: albo kończy się niepowodzeniem, przynajmniej z perspektywy użytkownika. Gdyby mountmusiał sam utworzyć punkt montowania, miałby dwa punkty awarii, co uniemożliwiłoby zagwarantowanie czystego wycofania. Wyobraź sobie następujący scenariusz:

1. mount pomyślnie tworzy punkt montowania
2. mount próbuje zamontować nowy system plików w tym katalogu, ale kończy się niepowodzeniem
3. mount próbuje usunąć punkt montowania, ale kończy się niepowodzeniem

System kończy się efektem ubocznym niepowodzenia mount.

Oto kolejny:

1. umount pomyślnie odmontowuje system plików
2. umount próbuje usunąć punkt montowania, ale kończy się niepowodzeniem

A teraz, czy umountpowróci sukces czy porażka?

Kolejny przypadek, który może wystąpić:

Podczas uruchamiania podstawowy obraz tylko do odczytu jest ładowany do katalogu głównego. Więc chcesz to zmienić, jeśli chcesz kopać prawdziwy root. Możesz więc sobie wyobrazić, że mount syscall po prostu zamienia punkt romontowania na rw.

Tutaj wyobraźmy sobie, że masz problem z systemem plików w głównym punkcie montowania. Chciałbyś móc spróbować go naprawić. Dzięki nakładaniu się montowania możesz odmontować system plików i użyć fsckdostarczonego obrazu podstawowego do jego rozwiązania.

Ta funkcja może być również przydatna w systemach wymagających silnych zabezpieczeń, aby śledzić zmiany między ropartycją a rwjedną.

Zawsze też się nad tym zastanawiałem.

Proste opakowanie, takie jak:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

zapisany jako skrypt wykonywalny o nazwie mountw katalogu nadpisującym /binw ŚCIEŻCE powinien się tym zająć, jeśli zbytnio Ci to przeszkadza

(Przed uruchomieniem rzeczywistego mountpliku binarnego tworzy katalog nazwany na podstawie ostatniego argumentu mount, jeśli taki katalog jeszcze nie istnieje).

Alternatywnie, jeśli nie chcesz, aby nieudane wywołania mountopakowania tworzyły katalogi, możesz:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }