Perché dobbiamo montare su Linux?

Comprendo cosa sia il montaggio in Linux e comprendo i file del dispositivo. Tuttavia non capisco PERCHÉ dobbiamo montare.

Ad esempio, come spiegato nella risposta accettata di questa domanda , usando questo comando:

mount /dev/cdrom /media/cdrom

stiamo montando il dispositivo CDROM /media/cdrome alla fine siamo in grado di accedere ai file di CDROM con il seguente comando

ls /media/cdrom

che elencherà il contenuto del CD-ROM.

Perché non saltare del tutto il montaggio e procedere come segue?

ls /dev/cdrom

E avere il contenuto del CD-ROM elencato. Mi aspetto che una delle risposte sia: " Ecco come è progettato Linux ". Ma se è così, allora perché è stato progettato in questo modo? Perché non accedere /dev/cdromdirettamente alla directory? Qual è il vero scopo del montaggio?

Uno dei motivi è che l'accesso a livello di blocco è un po 'più basso di quanto lssarebbe in grado di lavorare. /dev/cdrom, o dev/sda1potrebbe essere l'unità CD ROM e la partizione 1 del disco rigido, rispettivamente, ma non implementano ISO 9660 / ext4: sono solo puntatori RAW a quei dispositivi noti come File dispositivo .

Una delle cose che mount determina è COME usare quell'accesso non elaborato: quali logici / driver / moduli del kernel file system gestiranno le letture / scritture o tradurranno ls /mnt/cdromin quali blocchi devono essere letti e come interpretare il contenuto di questi blocchi in cose come file.txt.

Altre volte, questo accesso di basso livello può essere abbastanza buono; Ho appena letto e scritto su porte seriali, dispositivi USB, terminali tty e altri dispositivi relativamente semplici. Non proverei mai a leggere / scrivere manualmente da / dev / sda1 per, per esempio, modificare un file di testo, perché sostanzialmente dovrei reimplementare la logica ext4, che potrebbe includere, tra le altre cose: cercare gli inode dei file, trovare il blocchi di memoria, leggere l'intero blocco, apportare le mie modifiche, scrivere i blocchi completi, quindi aggiornare l'inode (forse) o invece scrivere tutto questo sul journal - troppo difficile.

Un modo per vederlo da solo è provarlo:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devè una directory e tu puoi cde lstutto ciò che ti piace. /dev/sda1non è una directory; è un tipo speciale di file che è ciò che il kernel offre come "handle" a quel dispositivo.

Vedi la voce di Wikipedia su File dispositivo per un trattamento più approfondito.

Fondamentalmente, e per dirla facilmente, il sistema operativo deve sapere come accedere ai file su quel dispositivo.

mount non è solo "darti accesso ai file", ma dice al sistema operativo il filesystem che ha il disco, se è di sola lettura o accesso di lettura / scrittura, ecc.

/dev/cdromè un dispositivo di basso livello, le funzioni del sistema operativo non saprebbero come accedervi ... immagina di inserire un cdrom formattato in modo strano (anche un cd audio), come lsdire quali file (se ce ne sono) presenti il cd-rom senza "montarlo" prima?

Si noti che ciò accade automaticamente in molti sistemi operativi (anche Linux su alcune distribuzioni e interfacce grafiche), ma ciò non significa che altri sistemi operativi non stiano "montando" le unità.

Per coerenza

Immagina di avere alcune partizioni sul primo disco rigido del tuo sistema. Ad esempio /dev/sda2,. Successivamente decidi che l'unità non è abbastanza grande, quindi ne acquisti una seconda e la aggiungi al sistema. All'improvviso, questo diventa /dev/sdae il tuo disco attuale diventa /dev/sdb. La tua partizione è adesso /dev/sdb2.

Utilizzando il sistema proposto, dovresti modificare tutti gli script, le applicazioni, le impostazioni, ecc. Che accedono ai dati sulla tua vecchia partizione per riflettere questa modifica nei nomi.

Tuttavia, il montaggio consente di utilizzare ancora lo stesso punto di montaggio per questa unità rinominata. Dovresti modificare /etc/fstabper dire al tuo sistema che (ad esempio) /media/backupè ora /dev/sdb2invece, ma questa è solo una modifica.

Si noti che i sistemi moderni sono ancora più facili. Invece di fare riferimento al dispositivo come /dev/sda2o /dev/sdb2, hanno UUIDS, che sembrano simili c5845b43-fe98-499a-bf31-4eccae14261bo possono avere etichette più amichevoli come quelle backupche possono essere utilizzate per fare riferimento al dispositivo durante il montaggio. In questo modo, il nome del dispositivo non cambia quando si aggiunge un nuovo dispositivo che rende l'amministrazione ancora più semplice:

# mount LABEL="backup" /media/backup

Per sicurezza

Richiedendo il montaggio di un dispositivo, l'amministratore può controllare l'accesso al dispositivo. Il dispositivo può essere rimosso quando smontato, ma non quando è in uso (a meno che non si desideri subire la perdita di dati). Se sei (eri) un utente Windows, ricordi la piccola icona verde nell'area di notifica che ti dice che è sicuro rimuovere una chiavetta USB? Questo è il montaggio di Windows e lo smontaggio del bastone per te. Quindi il principio non è solo uno Unix / Linux.

Lo definirei ragioni storiche. Non che le altre risposte siano sbagliate, ma c'è un po 'di più nella storia.

Confronta Windows: Windows è stato avviato come sistema operativo per singolo utente e singolo computer. Quel singolo computer probabilmente aveva un'unità floppy e un disco rigido, nessuna connessione di rete, nessuna USB, niente di niente. (Windows 3.11 aveva funzionalità di rete native; Windows 3.1 no .)

Il tipo di impostazione in cui è nato Windows era così semplice che non c'era bisogno di essere fantasiosi: basta montare tutto (tutti e due i dispositivi) automaticamente ogni volta, non ci sono (non c'erano) molte cose che potrebbero andare storto.

Al contrario, Unix è stato progettato per funzionare su reti di server con più utenti sin dall'inizio.

Una delle decisioni di progettazione di Unix è stata che il file system doveva apparire come un'unica entità uniforme per gli utenti finali, indipendentemente dal numero di computer su cui erano distribuiti i dischi fisici, indipendentemente dal tipo di disco e da quale dozzina di computer l'utente accedervi da. Il percorso logico dei file dell'utente rimarrebbe lo stesso, anche se la posizione fisica di tali file fosse cambiata durante la notte, ad esempio a causa della manutenzione del server.

Stavano astraggendo il file system logico, i percorsi dei file, dai dispositivi fisici che memorizzavano quei file. Supponiamo che il server A sia normalmente di hosting / home, ma il server A necessita di manutenzione: basta smontare il server A e montare invece il server di backup B su / home, e nessuno a parte gli amministratori lo noterebbe.
(A differenza della convenzione di Windows di assegnare nomi diversi a diversi dispositivi fisici - C :, D :, ecc. - che si oppone alla trasparenza per cui Unix si sforzava.)

In quel tipo di ambientazione, non puoi semplicemente montare tutto in vista, volenti o nolenti,

In una grande rete, singoli dischi e computer sono costantemente fuori servizio. Gli amministratori hanno bisogno della capacità di dire cosa è montato dove e quando, ad esempio per fare uno spegnimento controllato di un computer mentre un altro computer assume in modo trasparente l'hosting degli stessi file.

Ecco perché da una prospettiva storica: Windows e Unix provenivano da ambienti diversi. Potresti chiamarlo una differenza culturale, se ti piace:

• Unix è nato in un ambiente in cui l'amministratore doveva controllare il montaggio; delle dozzine di dispositivi di archiviazione in rete l'amministratore deve decidere cosa è montato dove e quando.
• Windows è nato in un'impostazione in cui non c'erano amministratori e solo due dispositivi di archiviazione e l'utente avrebbe probabilmente saputo se il loro file era sul floppy o sul disco rigido.
• (Linux è nato come sistema operativo per singolo computer, ovviamente, ma è stato anche progettato esplicitamente fin dall'inizio per imitare Unix il più vicino possibile su un computer di casa.)

Più recentemente, i sistemi operativi si sono avvicinati:

• Linux ha aggiunto più contenuti per singolo computer e per singolo utente (come il montaggio automatico); poiché veniva spesso utilizzato nelle impostazioni del singolo computer.
• Windows ha aggiunto maggiore sicurezza, rete, supporto per più utenti ecc .; man mano che le reti diventavano sempre più diffuse e Microsoft ha iniziato a creare anche un sistema operativo per server.

Ma è ancora facile dire che i due sono il risultato di tradizioni diverse.

La disposizione attuale presenta numerosi vantaggi. Possono essere raggruppati in vantaggi di file speciali a blocchi e vantaggi di mountpoint.

I file speciali sono file che rappresentano i dispositivi. Una delle idee su cui è stato basato unix è che tutto è un file. Ciò semplifica molte cose, ad esempio l'interazione dell'utente è solo la lettura e la scrittura di file su un dispositivo tty, che è un file speciale di carattere. allo stesso modo la verifica di blocchi danneggiati, il partizionamento o la formattazione di un disco sono solo operazioni sui file. Non importa se il disco è mfm, ide, scsi, fiberchanel o qualcos'altro, è solo un file.

D'altra parte, potresti non voler gestire l'intero disco o partizionare solo i file, e in molti casi più file di quelli che si adatteranno su un disco. Quindi abbiamo punti di montaggio. Un mountpoint consente di inserire un intero disco (o partizione) in una directory. Ai miei tempi di Slackware, quando un disco rigido di buone dimensioni era di circa duecento MB, era comune usare il CD come / usr e il disco rigido per /, / usr / local e swap. Oppure potresti mettere / su un disco e / home su un altro.

Ora ho notato che hai menzionato il montaggio del tuo CD su / media / cdrom, che è utile per i computer con una sola unità cdrom, ma cosa succede se ne hai più di una? dove dovresti montare il secondo? o il terzo? o il quindicesimo? potresti certamente usare / media / cdrom2, ecc. Oppure puoi montarlo su / src / samba / resources / windows-install, o / var / www, o ovunque abbia senso farlo.

Il titolo della domanda chiede: Perché dobbiamo montare su Linux?

Un modo di interpretare questa domanda: perché dobbiamo emettere mountcomandi espliciti per rendere disponibili i file system su Linux?

La risposta: noi no.

Non è necessario montare esplicitamente i file system, è possibile provvedere affinché sia ​​fatto automaticamente e le distribuzioni Linux lo fanno già per la maggior parte dei dispositivi, proprio come fanno Windows e Mac.

Quindi probabilmente non è quello che intendevi chiedere.

Una seconda interpretazione: perché a volte dobbiamo emettere mountcomandi espliciti per rendere disponibili i file system su Linux? Perché non fare in modo che il sistema operativo lo faccia sempre per noi e nasconderlo all'utente?

Questa è la domanda che sto leggendo nel testo della domanda, quando chiedi:

Perché non saltare del tutto il montaggio e procedere come segue

ls /dev/cdrom

e hai elencato il contenuto del CD-ROM?

Presumibilmente, vuoi dire: perché non avere semplicemente quel comando che fa cosa

ls /media/cdrom

fa adesso?

Bene, in tal caso, /dev/cdromsarebbe un albero di directory, non un file di dispositivo. Quindi la tua vera domanda sembra essere: perché in primo luogo avere un file dispositivo?

Vorrei aggiungere una risposta a quelle già fornite.

Perché gli utenti possono vedere i file del dispositivo?

Ogni volta che si utilizza un CD-ROM o qualsiasi altro dispositivo che memorizza i file, viene utilizzato un software che interpreta tutto ciò che è presente sul CD-ROM come un albero di directory di file. Viene invocato ogni volta che si utilizza lso qualsiasi altro tipo di comando o applicazione che accede ai file sul CD-ROM. Tale software è il driver del file system per il file system specifico utilizzato per scrivere i file sul CD-ROM. Ogni volta che elenchi, leggi o scrivi file su un file system, è compito di quel software assicurarsi che le corrispondenti operazioni di lettura e scrittura di basso livello vengano eseguite sul dispositivo in questione. Ogni volta che sei mountun file system, stai dicendo al sistema quale driver di file system utilizzare per il dispositivo. Se lo fai esplicitamente con amountcomando, o lasciarlo al sistema operativo per essere fatto automaticamente, dovrà essere fatto, e ovviamente il software del driver del file system dovrà essere lì in primo luogo.

Come fa un driver di file system a fare il suo lavoro? La risposta: lo fa leggendo e scrivendo nel file del dispositivo. Perché? La risposta, come hai già detto: Unix è stato progettato in questo modo. In Unix, i file dei dispositivi sono l'astrazione comune di basso livello per i dispositivi. Il software veramente specifico del dispositivo (il driver del dispositivo) per un particolare dispositivo dovrebbe implementare l'apertura, la chiusura, la lettura e la scrittura sul dispositivo come operazioni sul file del dispositivo. In questo modo, il software di livello superiore (come un driver del file system) non ha bisogno di sapere molto sul funzionamento interno dei singoli dispositivi. I driver di dispositivo di basso livello e i driver del file system possono essere scritti separatamente, da persone diverse, purché concordino un modo comune di interfacciarsi tra loro, ed è a questo che servono i file del dispositivo.

Quindi i driver del file system richiedono i file del dispositivo.

Ma perché noi comuni utenti possiamo vedere i file del dispositivo? La risposta è che Unix è stato progettato per essere utilizzato dai programmatori del sistema operativo. È stato progettato per consentire ai suoi utenti di scrivere driver di dispositivo e driver di file system. In effetti è così che vengono scritti.

Lo stesso vale per Linux: è possibile scrivere il proprio driver di file system (o driver di dispositivo), installarlo e quindi utilizzarlo. Rende Linux (o qualsiasi altra variante di Unix) facilmente estendibile (ed è in effetti la ragione per cui è stato avviato Linux): quando viene introdotto sul mercato un nuovo hardware, o viene progettato un nuovo modo più intelligente di implementare un file system , qualcuno può scrivere il codice per supportarlo, farlo funzionare e contribuire a Linux.

I file del dispositivo lo rendono più semplice.

Molti motori di database possono funzionare direttamente con dischi o partizioni non elaborati. Ad esempio, MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

Questo evita il sovraccarico di passare attraverso i driver del filesystem, quando tutto il motore DB ha davvero bisogno è un enorme file che riempie il disco.

Perché /dev/cdromè un dispositivo, mentre /media/cdromè un filesystem . È necessario montare il primo sul secondo per accedere ai file sul CD-ROM.

Il tuo sistema operativo sta già montando automaticamente i filesystem di root e utente dal tuo dispositivo a disco rigido fisico, quando avvii il computer. Questo sta solo aggiungendo più filesystem da usare.

Tutti i sistemi operativi lo fanno - tuttavia, alcuni (come Windows, quando monta un CD-ROM su D:) lo fanno in modo trasparente. Linux ti lascia in modo che tu abbia un maggiore controllo sul processo.

Lo fa perché c'è, con molti media per le UI desktop e laptop, l'ambiguità su cosa fare quando il media è inserito, perché l'intuizione dell'utente è che l'inserimento del disco nella scatola fisica con cui l'utente interagisce non è diverso, diciamo , inserendolo in un dispositivo accanto al computer che dispone di una connessione di rete.

Pertanto, nel senso fondamentale, l'interfaccia utente per i media deve trattare i due tipi di potenziali eventi di mount in modo simile e non esiste un buon modo per i computer di gestire i montaggi di rete nel modo più intuitivo possibile per i montaggi di rete con altre UI su computer, come smartphone, tablet e computer indossabili, che non hanno la possibilità di inserire supporti fisici nei dispositivi. (Nota quanto sia terribile l'interfaccia dell'iPhone per il cambio di schede SIM, l'unico tipo di dispositivo iOS fisico multimediale inserito in esse.

Si noti inoltre che altri approcci popolari alle UI per questo tipo di box fisico (ad esempio Windows 98, Windows 8, Mac OS X v10.2 (Jaguar) e Mac OS X v10.9 (Mavericks)) presentano gli stessi problemi e utilizzare finestre di dialogo della GUI aggiuntive per risolvere la potenziale confusione (ad esempio, Windows 8 è in genere configurato per richiedere ad ogni nuovo CD inserito se debba essere montato come un filesystem, un supporto musicale o, se appropriato, una raccolta di video MP4 ). Non vi è alcun motivo per cui nessuna di queste finestre di dialogo utente non possa essere utilizzata con Linux o altri UNIX.