Problemi con la comprensione del concetto di montaggio


13

Dopo aver letto entrambi Cosa si intende per montaggio di un dispositivo in Linux? e comprendendo "montare" come concetto nel sistema operativo , ho un problema in cui si afferma che

Tutta la memoria accessibile deve avere una posizione associata in questo singolo albero di directory. Ciò è diverso da Windows in cui (nella sintassi più comune per i percorsi dei file) esiste un albero di directory per componente di archiviazione (unità). Il montaggio è l'atto di associare un dispositivo di archiviazione a una posizione particolare nella struttura di directory.

Ma esiste già una posizione accessibile per dire un'unità cdrom in / dev / cdrom che ovviamente arriva nella gerarchia di directory. Quindi perché la necessità di creare un "mount point" separato in / media / cdrom? Perché l'accesso diretto da / dev / cdrom è reso impossibile? Ho sentito che i file del nodo del dispositivo sono proprio come i file ordinari. E leggere e scrivere per loro è proprio come i normali file. Questo significa che il filesystem nel cdrom non è disponibile se lo accediamo da / dev / cdrom. E la gerarchia del filesystem (all'interno del cdrom) "prende vita" quando la "montiamo"?

Risposte:


11

Puoi leggere o scrivere / dev / cdrom (ad es. Usando ddo cat) ma quando lo fai stai solo leggendo o scrivendo i byte grezzi del dispositivo. Ciò può essere utile in varie circostanze (come la clonazione di una partizione), ma in genere vogliamo vedere le directory e i file memorizzati sul dispositivo.

Quando montate un dispositivo, in pratica state dicendo al kernel di usare un livello di software (il driver del filesystem) per tradurre quei byte grezzi in un vero filesystem. Pertanto, il montaggio di un dispositivo associa il filesystem su quel dispositivo alla gerarchia di directory.


8

Ci penso nel modo seguente: mountè uno strumento che dice al sistema di interpretare il contenuto di alcuni file come alberi di directory.

  • Il filesystem ha directory e file e ogni file è un'etichetta per una stringa di byte.
  • /dev/cdrom è un file, rappresenta la stringa di byte memorizzati sul CD.
  • Puoi leggere direttamente questa stringa molto lunga, ma ciò non è molto pratico se non per scopi speciali (ad esempio la creazione di un'immagine del disco completa).
  • Questa lunga stringa ha una struttura interna aggiuntiva: contiene un file system, che contiene informazioni su quali directory e file sono memorizzati e dove in questa stringa molto lunga.
  • Usando mount -t iso9660 /dev/cdrom /media/cdrom, dici al sistema: "prendi questa lunghissima stringa di byte in cui ti trovi /dev/cdrom, interpretala come un albero di directory nel formato iso9660 e permettimi di accedervi dalla posizione /media/cdrom".
  • In effetti, questo funziona anche con file regolari. È possibile creare un file normale che contenga un'immagine del disco e quindi utilizzarlo mountper accedervi. Prova questo:
dd if = / dev / zero of = fs-image bs = 1M count = 50
mke2fs fs-image
sudo mount fs-image / some / mount / point

(i primi due comandi sono richiesti solo la prima volta, quando si prepara il file immagine.)


Perché ne hai bisogno mke2fs?
ADTC

Per creare un filesystem ext2 vuoto all'interno del file immagine. Un filesystem vuoto non è tutti zeri: ha alcuni metadati e strutture fisse, proprio come un documento Word o LibreOffice vuoto ha una dimensione diversa da zero e contiene informazioni su, ad esempio, il carattere predefinito e la dimensione della pagina.
Krzysztof Kosiński,

Oh OK, è un'azione potenzialmente distruttiva. Suggerire di menzionare che questo comando è solo per la prima inizializzazione. :)
ADTC,

5

/dev/cdromsi riferisce a un file del dispositivo . Questo non è il contenuto di qualsiasi disco che si possa desiderare di inserire nell'unità ottica, ma piuttosto è un riferimento al bit dell'hardware (e probabilmente ai driver del software) a cui si potrebbe fare appello per mostrarvelo. Quando si accede mount /dev/cdroma un percorso dell'albero, si allega il suo contenuto al file system .

Il fatto è che non riesco davvero a pensare a un altro modo di farlo. Anche in Windows - anche se non è così evidente - c'è ancora l'astrazione del filesystem per \\?\volumename\. Mi ci è voluto un minuto per ricordare che aspetto avesse, e l'ho trovato su Google :

... il nome del volume è solo un collegamento simbolico che rimanda a un dispositivo di volume reale, di solito sotto forma di \Device\HarddiskVolume23. C'è un altro esempio di un dispositivo MS-DOS che è la lettera di unità. Se il tuo volume ha la lettera di unità C: avrai un collegamento simbolico chiamato \\?\C: che punta a un volume reale nel \Device\HarddiskVolumeXXformato.

E quindi forse non è poi così diverso - anche se direi meno complicato - è solo più ovvio , penso. Non sono lo stesso sistema, ma non sono neanche fondamentalmente diversi.

Probabilmente la distinzione più importante tra /dev/deviceed /path/to/its/mountè che in quest'ultimo percorso un file system - un po 'di software destinato a gestire i dati in modo organizzato - sta interpretando il contenuto del primo. Non puoi semplicemente leggere un disco - qualcuno deve leggertelo. Il filesystem interpreta il contenuto del dispositivo.


Questo è in qualche modo fuorviante. Se si apre /dev/cdromin un editor esadecimale, in realtà contiene i contenuti non elaborati del CD-ROM. Usando mountdite semplicemente al sistema operativo di interpretare tali contenuti come un albero di directory.
Krzysztof Kosiński

0

Oltre agli elementi sopra menzionati, un driver o un altro programma può memorizzare nella cache i dati da un dispositivo. Su un dispositivo di lettura / scrittura, come un disco rigido o una chiavetta USB, i dati scritti sul dispositivo potrebbero non essere ancora stati scritti. I file system di journaling possono anche richiedere lo svuotamento del journal prima che non veda più il dispositivo. Quindi hai filesystem che si sovrappongono ad altri filesystem, come cryptfs, che devono sapere quando il filesystem sottostante non è più disponibile.

Certo, per un dispositivo di sola lettura questo ha meno senso, ma si applica comunque.

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.