Cosa succede quando si 'monta' su una cartella esistente con contenuti?


80

In questo momento /tmpha alcuni file temporanei in esso. Quando monto il mio disco rigido ( /dev/sdc1) sopra /tmp, posso vedere i file sul disco rigido. Cosa succede al contenuto effettivo di /tmpquando è montato il mio disco rigido? È possibile eseguire operazioni di r / w sul contenuto effettivo di /tmpmentre il disco rigido è montato?

python@lanix / $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       286G   43G  229G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            3.8G  4.0K  3.8G   1% /dev
tmpfs           766M  1.4M  765M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            3.8G   38M  3.8G   1% /run/shm
none            100M   24K  100M   1% /run/user
/dev/sdb1       7.5G  2.7G  4.9G  35% /mnt
/dev/sdc1       932G  242G  691G  26% /tmp

Risposte:


117

Cosa succede al contenuto effettivo di / tmp quando il mio disco rigido è montato?

Praticamente niente. Sono appena nascosti alla vista, non raggiungibili tramite il normale attraversamento del filesystem.

È possibile eseguire operazioni r / w sul contenuto effettivo di / tmp mentre il disco rigido è montato?

Sì. I processi con handle di file aperti all'interno del tuo "originale" /tmpcontinueranno ad essere in grado di usarli. Puoi anche fare in modo che "riappaia" altrove, montando il collegamento /altrove.

# mount -o bind / /somewhere/else
# ls /somewhere/else/tmp  

Ecco un piccolo esperimento che puoi eseguire per avere un'idea migliore (spero) di ciò che sta accadendo.

Nota: questo non è un tentativo di essere perfettamente corretto o una descrizione esaustiva di ciò che sta realmente accadendo. Dovrebbe essere solo abbastanza preciso da darti il ​​quadro generale però.

Ho creato un utente chiamato mesul mio computer e una directory casuale a casa sua, con un file al suo interno:

me@home $ pwd
/home/me/tmp
me@home $ echo hello > some_file
me@home $ ls  
some_file
me@home $ cat some_file 
hello

A questo punto, niente di insolito: è solo una directory semplice con un file semplice. Lascio quella sessione aperta così com'è, con la sua cwdall'interno di quella directory di test.

Come root, creo un piccolo filesystem e lo monto sopra /home/me/tmp.

root@home # dd if=/dev/zero of=./fs bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

root@home # mkfs -t ext2 ./fs 
mke2fs 1.42.12 (29-Aug-2014)
[... snip ...]
Writing superblocks and filesystem accounting information: done

root@home # mount ./fs /home/me/tmp

Quindi apro un nuovo terminale come mee mi guardo intorno:

me@home #2 $ cd tmp
me@home #2 $ ls
lost+found
me@home #2 $ cat some_file
cat: some_file: No such file or directory
me@home #2 $ echo bye bye > some_file
-su: some_file: Permission denied

Quindi, quel file che abbiamo creato non è chiaramente lì. La lost+founddirectory è indicativa della radice di un filesystem ext. E ho perso il permesso di scrittura, quindi chiaramente non è la directory originale.

Torna alla prima mesessione, diamo un'occhiata a come vede il mondo:

me@home $ echo something else > other_file

Nessun problema di scrittura.

me@home $ cat some_file other_file 
hello
something else

Il file originale è ancora lì, nuovo file creato senza problemi.

Eh? Cosa sta succedendo?

La prima sessione è entrata nella directory prima che fosse sovrapposta dal root montando un altro filesystem su di essa. Quell'azione di mount non influisce affatto sul filesystem originale. Il processo di shell ha un handle perfettamente valido per la directory nel filesystem originale e può continuare a interagire con esso. È una specie di correre sotto il punto di montaggio del tappeto .

La seconda sessione è entrata nella directory dopo l'installazione del mount. Quindi vede il nuovo filesystem vuoto. E l'amministratore di sistema ha bloccato le autorizzazioni, quindi non può utilizzare lo spazio richiesto ... consente di risolvere il problema.

root@home # chown me:users /home/me/tmp
me@home #2 $ echo bye bye > some_file
me@home #2 $ ls 
lost+found  some_file
me@home #2 $ cat some_file 
bye bye

La sessione 1 può sfuggire da sotto il tappeto? (Sta diventando ammuffito.)

Sicuro! Se la sessione 1 torna indietro dall'albero del filesystem dal mount, perderà quella maniglia all'interno e seguirà il mount come tutti gli altri.

me@home $ cd
me@home $ pwd
/home/me
me@home $ cd tmp
me@home $ cat some_file other_file
bye bye
cat: other_file: No such file or directory

Stessa visione della sessione n. 2, siamo tornati alla normalità.

Ma come fai a sapere che i file non sono scomparsi? Nessuno guarda più!

Questo è uno dei momenti in cui i supporti di collegamento sono utili. Ti permettono di montare un filesystem già montato altrove.

me@home $ mkdir ~/bind
root@home # mount -o bind /home/me /home/me/bind

(Sì, puoi legare un filesystem "dentro se stesso". Un bel trucco, eh?)

me@home $ ls bind/tmp
other_file  some_file
me@home $ cat bind/tmp/*
something else
hello

Quindi sono davvero lì, pronti all'azione. È semplicemente che non sono visibili / raggiungibili nella posizione originale, il mount li nasconde dai normali attraversamenti di directory.


Ti incoraggio a giocare con questo, non è davvero complicato una volta capito il "trucco" che si sta giocando. E una volta ottenuto Got It ™, dai un'occhiata ai filesystem union per ottenere ancora più tappeti :-)

Una nota però: il montaggio su /tmpo /var(o su una qualsiasi delle directory del SO principale) non è davvero una buona idea una volta terminato il processo di avvio. Molte applicazioni lasciano lo stato in quelle directory e potrebbero essere seriamente confuse se giochi a mount mount attorno a loro.


4
Questa è un'ottima risposta: sei andato ben oltre ciò che ti ho chiesto. Anche l'idea di bind-mount è piuttosto interessante! Grazie per la risposta dettagliata Saluti.
utente

11
Questo è un modo molto comune per perdere misteriosamente spazio su disco. Se un montaggio non riesce per qualsiasi motivo in uno script di avvio, i dati possono essere scritti nella directory sul filesystem di root. Se viene quindi tentato un riavvio, il montaggio può avere esito positivo e forse nessuno se ne accorgerà (ad esempio, se il file system contiene file o registri tmp), tranne per il fatto che occuperà spazio, forse molto.
Dan Sheppard,

2
@DanSheppard Questo è uno dei motivi per cui mi piacciono i miei mount points chmod 000. Anche perché systemd fallisce l'avvio se i mount critici falliscono.
Zan Lynx,

Potresti anche -bind montare /home/mesu /home/meinvece della cartella "bind"? Vale a dire mettere un altro tappeto sopra il tappeto. O dovresti smontare fsprima?
jiggunjer,

@jiggunjer Sembra che l' unionopzione possa aiutare.
hliu,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.