Perché il montaggio avviene su una directory esistente?

È necessaria una directory esistente come punto di montaggio .

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

Lo trovo confuso poiché si sovrappone ai contenuti esistenti della directory. Esistono due possibili contenuti della directory del punto di montaggio che possono essere commutati in modo imprevisto (per un utente che non sta eseguendo il montaggio).

Perché non mountaccade in una directory appena creata? Questo è il modo in cui i sistemi operativi grafici visualizzano i supporti rimovibili. Sarebbe chiaro se la directory è montata (esiste) o non montata (non esiste). Sono abbastanza sicuro che ci sia una buona ragione, ma non sono stato ancora in grado di scoprirlo.

Questo è il caso di un dettaglio di implementazione che è trapelato.

In un sistema UNIX, ogni directory è composta da un elenco di nomi associati a numeri di inode . Un inode contiene metadati che indicano al sistema se si tratta di un file, una directory, un dispositivo speciale, una pipe denominata, ecc. Se si tratta di un file o di una directory, indica anche al sistema dove trovare il contenuto del file o della directory sul disco. La maggior parte degli inode sono file o directory. L' -iopzione per lselencare i numeri di inode.

Montare un filesystem prende un inode di directory e imposta un flag sulla copia in memoria del kernel per dire "in realtà, quando cerchi il contenuto di questa directory guarda invece questo altro filesystem" (vedi slide 10 di questa presentazione ). Questo è relativamente semplice in quanto sta cambiando un singolo elemento di dati.

Perché non crea invece una voce di directory che punta al nuovo inode? Esistono due modi per implementarlo, entrambi i quali presentano degli svantaggi. Uno è scrivere fisicamente una nuova directory nel filesystem - ma ciò fallisce se il filesystem è di sola lettura! L'altro è quello di aggiungere a ogni processo di elenco delle directory un elenco di cose "extra" che non sono realmente presenti. Questo è complicato e potenzialmente comporta un piccolo calo delle prestazioni su ogni operazione di file.

Se desideri punti di montaggio creati dinamicamente, il automountsistema può farlo. Filesystem non-disco speciali possono anche creare directory a piacere, ad esempio proc, sys, devfse così via.

Modifica: vedi anche la risposta a Cosa succede quando 'monti' una cartella esistente con contenuti?

Se è mount(2) richiesta la creazione di una nuova directory come punto di montaggio, non è possibile montare nulla in un file system di sola lettura. Sarebbe stupido, quindi possiamo escluderlo.

Se mount opzionalmente creasse una nuova directory come mountpoint, sarebbe strano. Non è come montare / smontare avvenga continuamente, quindi inserire una logica aggiuntiva nel kernel per eseguire questi due passaggi con una singola chiamata di sistema non sarebbe un importante aumento di velocità. Lascialo allo spazio utente per effettuare una mkdir(2)chiamata di sistema se ne desidera una. La risposta di Dmitry sottolinea che mount(2)fare entrambe le cose lo renderebbe non atomico. E che ci si vuole un argomento in più per mount(2)con le bandiere del modo come open(2)avviene, per O_CREAT, O_EXCLecc sarebbe solo stupido paragonato a lasciare user-space farlo.

O forse ti stavi chiedendo di fare mount(8)(il tradizionale programma che effettua mount(2)chiamate di sistema)? Ciò sarebbe possibile, ma esiste già un ottimo strumento mkdir(1)per il lavoro e il design di Unix è incentrato su buoni piccoli strumenti che possono essere combinati. Se vuoi uno strumento che fa entrambe le cose, è facile scrivere uno script di shell per costruire quello strumento con due strumenti più semplici. (O, come ha commentato Muru, lo udisksctlfa già, quindi non è necessario scriverlo.) Inoltre, il normale Linux mount(8)da util-linux supporta l' mount -o x-mount.mkdir[=mode]utilizzo della sua x-sintassi per le opzioni per userspace, piuttosto che le opzioni da passare al filesystem.

Ora la domanda più interessante: perché ci deve essere una directory sul filesystem genitore?

Come sottolinea la risposta di pjc50 (nessuna relazione, anche se ha le mie iniziali!), Avere punti di mount mostrati negli elenchi delle directory richiederebbe un controllo extra su ogni readdir().

Avere punti di mount esistono come directory nella directory che li contiene (sul FS padre) è un bel trucco. readdir()non è necessario notare che si tratta di un mount point. Ciò accade solo se il punto di montaggio viene utilizzato come componente del percorso. Naturalmente la risoluzione del percorso deve controllare la tabella di montaggio per ogni componente della directory di un percorso.

Il montaggio su una directory esistente fa una chiamata mountpraticamente atomica: ha successo o fallisce, almeno dal punto di vista dell'utente. Se mountdovesse creare il mountpoint stesso, avrebbe due punti di errore, rendendo impossibile garantire un rollback pulito. Immagina il seguente scenario:

1. mount crea correttamente il mountpoint
2. mount tenta di montare un nuovo file system in quella directory, ma non riesce
3. mount tenta di rimuovere il mountpoint, ma non riesce

Il sistema finisce con un effetto collaterale di un fallimento mount.

Eccone un altro:

1. umount smonta correttamente un file system
2. umount tenta di rimuovere il mountpoint, ma non riesce

Ora, dovrebbe umountrestituire successo o fallimento?

Un altro caso che può verificarsi:

All'avvio, un'immagine di sola lettura di base viene caricata nella directory principale. Quindi ti piacerebbe scavalcarlo quando vorresti montare la vera radice. Quindi puoi immaginare che mount syscall cambi semplicemente il romountpoint a rw.

Qui, immaginiamo di avere un problema con il filesystem sul mountpoint di root, vorresti poter provare a ripararlo. Con mount overlap, è possibile smontare il filesystem e utilizzare fsckl'immagine fornita di base per risolverlo.

Questa funzionalità può essere utile anche nei sistemi che richiedono una sicurezza elevata per tenere traccia delle modifiche tra una ropartizione e una rw.

Mi sono sempre chiesto anche questo.

Un semplice wrapper come:

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

salvato come uno script eseguibile chiamato mountin una directory che ha la precedenza /binsul tuo PERCORSO dovrebbe occupartene se ti dà troppo fastidio

(Prima di eseguire il file mountbinario effettivo , crea una directory denominata dopo l'ultimo argomento mount, se tale directory non esiste già.)

In alternativa, se non si desidera invocazioni non riuscite del mountwrapper per creare directory, è possibile effettuare:

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