Perché il filesystem di Linux è progettato come un singolo albero di directory?

Qualcuno può spiegare perché Linux è progettato come un singolo albero di directory?

Considerando che in Windows possiamo avere più unità simili C:\e D:\, c'è un unico root in Unix. Qualche motivo specifico lì?

Poiché il file system Unix precede Windows di molti anni, si potrebbe riformulare la domanda "perché Windows utilizza un designatore separato per ogni dispositivo?".

Un filesystem gerarchico ha il vantaggio di poter trovare qualsiasi file o directory come figlio della directory root. Se è necessario spostare i dati su un nuovo dispositivo o un dispositivo di rete, la posizione nel file system può rimanere la stessa e l'applicazione non vedrà la differenza.

Supponiamo di avere un sistema in cui il sistema operativo è statico e esiste un'applicazione con requisiti di I / O elevati. Puoi montare / usr in sola lettura e mettere / opt (se l'app vive lì) su unità SSD. La gerarchia del filesystem non cambia. Sotto Windows questo è molto più difficile, in particolare con le applicazioni che insistono per vivere in C: \ Programmi \

Questo è in parte per motivi storici e in parte perché ha più senso in questo modo.

Multics

Multics è stato il primo sistema operativo a introdurre il file system gerarchico come lo conosciamo oggi, con directory che possono contenere directory. Citando "Un file system per scopi generici per l'archiviazione secondaria" di RC Daley e PG Neumann:

La sezione 2 dell'articolo presenta la struttura gerarchica dei file, che consente un uso flessibile del sistema. Questa struttura contiene capacità sufficienti per assicurare versatilità. (...)

Per facilità di comprensione, la struttura dei file può essere pensata come un albero di file, alcuni dei quali sono directory. Cioè, con una sola eccezione, ogni file (ad esempio, ogni directory) si trova direttamente puntato da esattamente un ramo in esattamente una directory. L'eccezione è la directory principale, o radice, nella radice dell'albero. Sebbene non sia esplicitamente indicato da alcuna directory, la radice è implicitamente indicata da un ramo fittizio noto al file system. (...)

In qualsiasi momento, si considera che un utente operi in una directory, chiamata directory di lavoro. Può accedere a un file effettivamente indicato da una voce nella sua directory di lavoro semplicemente specificando il nome della voce. Più utenti possono avere la stessa directory di lavoro alla volta.

Come in molti altri aspetti, Multics ha cercato la flessibilità. Gli utenti possono lavorare in una sottostruttura del filesystem e ignorare il resto, e comunque beneficiare delle directory per organizzare i propri file. Le directory sono state usate anche per il controllo degli accessi: l'attributo READ ha permesso agli utenti di elencare i file in una directory e l'attributo EXECUTE ha permesso agli utenti di accedere ai file in quella directory (questo, come molte altre funzionalità, viveva su unix).

Multics ha anche seguito il principio di avere un singolo pool di archiviazione. Il documento non si sofferma su questo aspetto. Un singolo pool di archiviazione era una buona corrispondenza con l'hardware del tempo: non c'erano dispositivi di archiviazione rimovibili, almeno nessuno a cui gli utenti si sarebbero preoccupati. Multics aveva un pool di archiviazione di backup separato, ma ciò era trasparente per gli utenti.

Unix

Unix ha preso molta ispirazione da Multics, ma puntava alla semplicità, mentre Multics puntava alla flessibilità.

Un singolo filesystem gerarchico si adattava bene a Unix. Come con Multics, i pool di archiviazione di solito non erano rilevanti per gli utenti. Tuttavia, c'erano dispositivi rimovibili e Unix li ha esposti agli utenti tramite i comandi mounte umount(riservati al "superutente", ovvero all'amministratore). In "Il sistema di condivisione del tempo UNIX" , Dennis Ritchie e Ken Thompson spiegano:

Sebbene la radice del file system sia sempre memorizzata sullo stesso dispositivo, non è necessario che l'intera gerarchia del file system risieda su questo dispositivo. Esiste una richiesta di sistema di montaggio con due argomenti: il nome di un file ordinario esistente e il nome di un file speciale il cui volume di archiviazione associato (ad esempio un pacchetto di dischi) dovrebbe avere la struttura di un file system indipendente contenente la propria gerarchia di directory . L'effetto di mount è di fare in modo che i riferimenti al file ordinario precedente facciano invece riferimento alla directory principale del file system sul volume rimovibile. In effetti, mount sostituisce una foglia dell'albero della gerarchia (il file ordinario) con una sottostruttura completamente nuova (la gerarchia memorizzata nel volume rimovibile). Dopo il montaggio, non esiste praticamente alcuna distinzione tra i file nel volume rimovibile e quelli nel file system permanente. Nella nostra installazione, ad esempio, la directory principale si trova su una piccola partizione di una delle nostre unità disco, mentre l'altra unità, che contiene i file dell'utente, è montata dalla sequenza di inizializzazione del sistema. Un file system montabile viene generato scrivendo sul file speciale corrispondente. È disponibile un programma di utilità per creare un file system vuoto oppure si può semplicemente copiare un file system esistente.

Il filesystem gerarchico ha anche il vantaggio di concentrare la complessità della gestione di più dispositivi di archiviazione nel kernel. Ciò significava che il kernel era più complesso, ma di conseguenza tutte le applicazioni erano più semplici. Dal momento che il kernel deve preoccuparsi dei dispositivi hardware ma la maggior parte delle applicazioni no, questo è un design più naturale.

finestre

Windows fa risalire i suoi antenati a due linee: VMS , un sistema operativo originariamente progettato per il minicomputer VAX , e CP / M , un sistema operativo progettato per i primi microcomputer Intel.

VMS aveva un filesystem gerarchico distribuito, Files-11 . In Files-11, il percorso completo di un file contiene un nome nodo, una designazione di account su quel nodo, un nome dispositivo, un percorso dell'albero di directory, un nome file, un tipo di file e un numero di versione. VMS aveva una potente funzione di nome logico che consente di definire collegamenti a directory specifiche, quindi gli utenti raramente dovrebbero preoccuparsi della posizione "reale" di una directory.

CP / M è stato progettato per computer con 64kB di RAM e un'unità floppy, quindi è andato per semplicità. Non c'erano directory, ma un riferimento al file potrebbe includere un'indicazione ( A:o B:) dell'unità .

Quando MS-DOS 2.0 ha introdotto le directory, lo ha fatto con una sintassi compatibile con MS-DOS 1 che a sua volta ha seguito CP / M. Quindi i percorsi sono stati radicati su un'unità con un nome di una sola lettera. (Inoltre, il carattere barra è /stato utilizzato in VMS e CP / M per avviare le opzioni della riga di comando, quindi è stato necessario utilizzare un carattere diverso come separatore di directory. Ecco perché DOS e Windows utilizzano la barra rovesciata, sebbene alcuni componenti interni supportino anche la barra ).

Windows ha mantenuto la compatibilità con DOS e l'approccio VMS, quindi ha mantenuto l'idea di lettere di unità anche quando sono diventate meno rilevanti. Oggi, sotto il cofano, Windows utilizza percorsi UNC ( originariamente sviluppati da Microsoft e IBM per OS / 2 , di origine correlata). Sebbene questo sia riservato agli utenti esperti (probabilmente a causa del peso della cronologia), Windows consente il montaggio tramite punti di analisi .

Non ci sono problemi di sicurezza dietro avere un singolo albero di directory.

I ragazzi che hanno progettato Unix avevano una vasta esperienza con i sistemi operativi che richiedevano agli utenti di sapere quale dispositivo fisico conteneva una determinata risorsa. Poiché parte dello scopo di un sistema operativo è quello di creare una macchina astratta su hardware reale, hanno pensato che fosse molto più semplice rinunciare a indirizzare le risorse in base alla loro posizione fisica e hanno deciso di inserire tutto in un unico albero di nomi.

Questa è solo una parte del genio alla base del design di Unix .

Si noti che i nomi delle lettere di unità da MS-DOS che persistono nelle moderne finestre sono un'aringa rossa qui. I nomi delle lettere di unità non sono la migliore rappresentazione di una struttura di file system che ha più radici. Sono un'implementazione di paglia di tale sistema.

Un filesystem correttamente implementato che supporta più radici consentirebbe nomi arbitrari per i volumi, come dvdrom:/path/to/file.avi. Tale sistema eliminerebbe i risibili problemi dell'interfaccia utente che affliggono Windows. Ad esempio, se si collega un dispositivo come una fotocamera, l'interfaccia utente di Windows Explorer ti fa credere che esiste un dispositivo chiamato Camera (o qualsiasi altra cosa) e che hai un percorso simile Computer\Camera\DCIM\.... Tuttavia, se si taglia e incolla la versione testuale di questo percorso da Explorer, in realtà non funziona perché alcuni dei componenti del percorso sono una finzione dell'interfaccia utente, non nota al sistema operativo sottostante. IN un sistema correttamente implementato con più radici, andrebbe bene: ci sarebbe uncamera:\DCIM\...percorso riconosciuto uniformemente a tutti i livelli del sistema. Inoltre, se esegui il porting su un vecchio disco rigido da un vecchio PC, non rimarrai bloccato con un nome di lettera di unità simile F:, ma piuttosto sarai in grado di nominarlo come vuoi, come old-disk:.

Quindi, se Unix avesse più radici nella struttura del filesystem, sarebbe fatto in questo modo in modo sano, e non come in MS-DOS e Windows con nomi di unità di una lettera. In altre parole, confrontiamo solo lo schema Unix con un buon design multi-root.

Quindi, perché Unix non ha un'implementazione sana a più radici, a favore dell'implementazione sana a una radice? Probabilmente è solo per semplicità. I punti di montaggio offrono tutte le funzionalità per poter accedere ai volumi tramite nomi. Non è necessario estendere lo spazio dei nomi con una sintassi del prefisso aggiuntiva.

Matematicamente parlando, ogni grafico ad albero disgiunto ("foresta") può essere unito aggiungendo un nodo radice e trasformando i pezzi disgiunti in figli.

Inoltre, è più flessibile che i volumi non debbano essere al livello principale. Poiché non esiste una sintassi speciale che denota il volume (è solo un componente del percorso), i punti di montaggio possono essere ovunque. Se si mettono in tre vecchi dischi al vostro computer, è possibile avere come /old-disk/one, /old-disk/twoecc È possibile organizzare i dischi come vuoi, il modo di organizzare i file e le directory.

È possibile scrivere applicazioni che dipendono dai percorsi e che la validità dei percorsi può essere mantenuta quando i dispositivi di archiviazione vengono riconfigurati. Ad esempio, le applicazioni possono utilizzare percorsi noti come /var/loge /var/lib. Dipende da te se /var/loge /var/libsono sullo stesso volume del disco o su quelli separati. È possibile migrare un sistema in una nuova topologia di archiviazione, preservando i percorsi.

I punti di montaggio sono una buona idea, motivo per cui Windows li ha avuti da circa Windows 2000.

I punti di montaggio del volume sono robusti rispetto alle modifiche di sistema che si verificano quando i dispositivi vengono aggiunti o rimossi da un computer. Microsoft Technet

Sia * nix che Windows montano le loro unità. In Windows questi vengono automaticamente montati in punti di montaggio che, per impostazione predefinita, sono in ordine alfabetico crescente. Queste impostazioni predefinite sono:

• A:e B:=> floppy
• C: => prima partizione del primo disco rigido
• D: => partizione successiva o disco rigido successivo o unità CD / DVD se non sono presenti altre partizioni.

Ognuno di questi punti di montaggio è una directory.

In * nix, i punti di montaggio sono decisi dall'utente. Ad esempio, ho una partizione montata come /e un'altra come /home. Quindi, /homeè un'unità separata, sarebbe l'equivalente di dire E:su Windows.

In entrambi i casi, Windows e * nix, i punti di montaggio sono directory separate. L'unica differenza è che in * nix, queste directory separate sono sottodirectory di /, C:mentre in Windows ogni punto di mount è montato direttamente sotto /, My Computerdiciamo.

Dal punto di vista dell'utente, il vantaggio principale è che i supporti sono completamente trasparenti. Non ho bisogno di sapere che la directory /homeè in realtà su una partizione separata. Posso semplicemente usarlo come una normale directory. Invece, in DOS, dovrei chiamarlo esplicitamente con il nome del punto di mount, diciamoE:\home

Le unità esterne sono montate praticamente allo stesso modo in entrambi i sistemi. Dire D:per Windows e /mnt/cdromper Linux. Ognuna di queste è una directory, non vedo davvero la differenza. Quando si inserisce un CD-ROM nell'unità in Windows, il disco viene montato D:esattamente come in Linux.

Sono d'accordo con le risposte di cui sopra, in particolare la risposta di Doug O'Neal, ma penso che a tutti manchi qualcosa, così come i punti di montaggio espliciti del dispositivo come MS-DOS "C:" o "A:".

Rob Pike scrisse The Hideous Name sulla sintassi dei nomi, ma Russ Cox lo ridusse :

Gli spazi dei nomi ... sono più potenti quando è possibile aggiungere una nuova semantica senza aggiungere nuova sintassi.

Un unico spazio dei nomi in cui i dispositivi possono essere montati arbitrariamente consente operazioni davvero flessibili. Uso regolarmente /mnt/sdb1e /mnt/cdromcolloco temporaneamente un disco o CD attualmente inutilizzato nel file system generale. Non è affatto raro avere home directory su un server NFS, quindi indipendentemente dalla macchina alla quale si accede, si ottiene lo stesso $HOMEovunque.

Tutto dipende da questo: avere una sintassi speciale per cose speciali pone dei limiti definiti su ciò che puoi fare. Se puoi montare solo un disco o CD o DVD inutilizzato, o un filesystem di rete / "condivisione" su "E:" o "W:" o qualsiasi altra cosa, hai molta meno flessibilità.

Questo è sciocco. Windows ha anche un singolo punto gerarchico. Ma è nascosto e non standard. Come molte altre finestre.

In questo caso, è il concetto di "Risorse del computer". Questo è l'equivalente di root (/) in Unix. Ricorda che root è un concetto che esiste nel kernel. ti piace o no. Proprio come Windows tratta "Risorse del computer". ovviamente, è possibile montare una partizione su root in unix, ed è quello che fanno la maggior parte delle persone. E molte cose guarderanno un percorso specifico per le cose (ad esempio / etc /) ma non ne sei limitato. Certamente, monta le tue unità in / C: /. non ti è proibito farlo in unix.

C: \ non è una radice in Windows, è il punto di montaggio di una partizione. Quale DEVE essere al livello superiore "Risorse del computer". Mentre in unix puoi montare una partizione sotto qualsiasi altro albero. Quindi Linux puoi avere C: montato /mentre tu hai D: montato /mnt/d/... o anche montato /ma è difficile e dipende da come si comportano i due file system quando si montano su un percorso già montato.

Quindi puoi ottenere esattamente lo stesso che hai con Windows "forzandoti" a seguire le stesse limitazioni che Windows ti impone in modo casuale.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Quindi dovresti passare nelle opzioni di montaggio nelle opzioni di avvio. dal momento che non avrai un / etc / ... ma questo simula anche i limiti imposti da windows, come quello che fa.

Il motivo per cui Windows ha lettere di unità probabilmente risale a più di Microsoft e DOS. L'assegnazione di lettere a unità rimovibili era comune sui sistemi IBM, quindi Microsoft potrebbe aver semplicemente seguito le istruzioni di IBM copiando CP / M. E inizialmente, DOS non aveva comunque directory.

Quando MS-DOS veniva eseguito su computer con uno o due dischi rimovibili e senza supporti fissi, non era necessario un file system con directory. Con uno o forse due dischi da 180 kilobyte, non hai mai avuto abbastanza file per avere problemi a organizzarli.

https://en.wikipedia.org/wiki/Drive_letter_assignment

In realtà, Linux è basato su Unix (o è Unix, vedi discussione ) e Unix proviene dall'ambiente mainframe, dove l'utilizzo di più dispositivi era abbastanza ovvio. Il montaggio di dispositivi all'interno di un singolo albero di directory offre la massima flessibilità e non limita il numero di dispositivi a cui il sistema operativo può accedere.

D'altra parte, le lettere DOS per le unità sono una buona progettazione per un PC con 1 o 2 stazioni floppy e unità disco singolo. Il grande floppy 5,25 'è sempre A :, quello piccolo 3,5' è sempre B: e l'unità disco è sempre C :. Sai sempre se copi un file sul floppy o da qualche parte sul disco. Non è necessaria alcuna flessibilità se non è possibile collegare fisicamente più di 2 unità floppy e 2 (o 4) dischi rigidi.

Il design DOS era più intuitivo per l'utente finale, mentre il design Unix è di facile utilizzo per l'amministratore. Ora le lettere di unità sono un peso per Windows, gli utenti si affidano più all'apertura automatica della finestra di Explorer con contenuto di unità rimovibile che alla conoscenza della sua lettera ... Ubuntu fa lo stesso, in realtà.

Questo non è vero, in realtà. Windows utilizza un altro schema di percorsi (beh, non è lo stesso)

"Lettere unitarie" sono solo qualcosa da ricordare facilmente percorsi, dischi e partizioni.

I percorsi ARC definiscono il percorso di un file in Windows (ma sono visibili all'utente solo all'avvio):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

In Windows NT non esiste alcuna relazione tra dischi, partizioni e lettere di unità: è possibile "mettere" un intero volume in una cartella (ad esempio: c: \ myseconddisk potrebbe essere un intero disco fisico!)

Due cose che vorrei sottolineare:

1. I dischi rigidi in Linux sono in realtà assegnati a lettere / nomi, come / dev / sdb1. Ma possono essere montati ovunque per essere raggiunti dalla struttura single / root
2. Il motivo più comune per cui le persone (incluso me stesso in passato) avevano unità separate in Windows era di avere un posto dove conservare documenti, musica, programmi, ecc. In modo che, quando inevitabilmente Windows doveva essere reinstallato o sostituito, che si trattasse di aggiornamento o virus o errore del file system, c'era ancora accesso a quei file. Non ho questo problema in Linux - il file system è molto più affidabile, il sistema operativo non si rompe se non con un'azione diretta o un errore da parte mia (ooh! Un repository all'avanguardia, proviamolo!) E aggiornamenti sono molto più semplici. E, nel raro caso che ho dovuto reinstallare, poiché tutto il software era disponibile tramite repository o ppa che ho aggiunto (e potevo facilmente copiare la mia home directory con un disco live),

Se guardi indietro alla storia, puoi anche vedere che Unix è stato avviato al momento dei sistemi a nastro a 8 tracce per i sistemi audio e dei dati IBM a 9 tracce (8 tracce / 8 bit per i dati, uno per parità). Tecnicamente praticamente la stessa cosa.

A quel tempo le informazioni sulla posizione dei file erano archiviate in parti delle informazioni su nastro e avanti e indietro definite quando si leggevano i dati dal nastro (come un file, con posizione iniziale e firma finale); spiega anche perché non avevi un solo FAT all'inizio del disco, ma ne avevi molti per accelerare la ricerca. E se avevi più unità, queste erano collegate all'interno di / dev e tramite l'indirizzo del file che hai spostato tra i dispositivi.

Credo che potresti pensare che sia iniziato semplicemente prima e che la decisione dietro l'area MS Dos (CP / M) e successivamente Windows NT sia semplicemente correlata alle lettere dell'unità mainframe della VM anziché a un singolo punto di ingresso perché al momento sembrava più moderni, non esistevano quantità di dati di oggi e non pensavano che alla fine non avresti avuto abbastanza lettere di unità o che sarebbe stata ingombra.

Assegnazione 9-Track-Drive e Drive Letter