¿Por qué el sistema de archivos de Linux está diseñado como un único árbol de directorios?

¿Alguien puede explicar por qué Linux está diseñado como un único árbol de directorios?

Mientras que en Windows podemos tener múltiples unidades como C:\, y D:\, hay una sola raíz en Unix. ¿Alguna razón específica allí?

Dado que el sistema de archivos Unix es anterior a Windows por muchos años, uno puede reformular la pregunta a "¿por qué Windows usa un designador separado para cada dispositivo?".

Un sistema de archivos jerárquico tiene la ventaja de que cualquier archivo o directorio se puede encontrar como hijo del directorio raíz. Si necesita mover datos a un nuevo dispositivo o dispositivo de red, la ubicación en el sistema de archivos puede permanecer igual y la aplicación no verá la diferencia.

Suponga que tiene un sistema donde el sistema operativo es estático y hay una aplicación que tiene altos requisitos de E / S. Puede montar / usr solo lectura y poner / optar (si la aplicación vive allí) en unidades SSD. La jerarquía del sistema de archivos no cambia. En Windows, esto es mucho más difícil, particularmente con aplicaciones que insisten en vivir bajo C: \ Archivos de programa \

Esto es en parte por razones históricas, y en parte porque tiene más sentido de esta manera.

Multics

Multics fue el primer sistema operativo en introducir el sistema de archivos jerárquico tal como lo conocemos hoy, con directorios que pueden contener directorios. Citando "Un sistema de archivos de uso general para almacenamiento secundario" por RC Daley y PG Neumann:

La Sección 2 del documento presenta la estructura jerárquica de los archivos, lo que permite un uso flexible del sistema. Esta estructura contiene capacidades suficientes para garantizar la versatilidad. (...)

Para facilitar la comprensión, la estructura de archivos puede considerarse como un árbol de archivos, algunos de los cuales son directorios. Es decir, con una excepción, cada archivo (por ejemplo, cada directorio) se encuentra directamente señalado por exactamente una rama en exactamente un directorio. La excepción es el directorio raíz, o raíz, en la raíz del árbol. Aunque no se señala explícitamente desde ningún directorio, la raíz se señala implícitamente mediante una rama ficticia que el sistema de archivos conoce. (...)

En cualquier momento, se considera que un usuario está operando en algún directorio, llamado su directorio de trabajo. Puede acceder a un archivo efectivamente señalado por una entrada en su directorio de trabajo simplemente especificando el nombre de la entrada. Más de un usuario puede tener el mismo directorio de trabajo a la vez.

Como en muchos otros aspectos, Multics buscó flexibilidad. Los usuarios pueden trabajar en un subárbol del sistema de archivos e ignorar el resto, y aún así beneficiarse de los directorios para organizar sus archivos. Los directorios también se usaron para el control de acceso: el atributo READ permitió a los usuarios enumerar los archivos en un directorio, y el atributo EXECUTE permitió a los usuarios acceder a los archivos en ese directorio (esto, como muchas otras características, vivía en Unix).

Multics también siguió el principio de tener un único grupo de almacenamiento. El documento no se detiene en este aspecto. Un único grupo de almacenamiento era una buena combinación con el hardware de la época: no había dispositivos de almacenamiento extraíbles, al menos ninguno que a los usuarios les importara. Multics tenía un grupo de almacenamiento de respaldo separado, pero esto era transparente para los usuarios.

Unix

Unix se inspiró mucho en Multics, pero apuntó a la simplicidad, mientras que Multics apuntó a la flexibilidad.

Un único sistema de archivos jerárquico se adaptaba bien a Unix. Al igual que con Multics, los grupos de almacenamiento generalmente no eran relevantes para los usuarios. Sin embargo, había dispositivos extraíbles, y Unix los expuso a los usuarios, a través de los comandos mounty umount(reservados para el "superusuario", es decir, el administrador). En "El sistema de tiempo compartido UNIX" , Dennis Ritchie y Ken Thompson explican:

Aunque la raíz del sistema de archivos siempre se almacena en el mismo dispositivo, no es necesario que toda la jerarquía del sistema de archivos resida en este dispositivo. Hay una solicitud de sistema de montaje con dos argumentos: el nombre de un archivo ordinario existente y el nombre de un archivo especial cuyo volumen de almacenamiento asociado (por ejemplo, un paquete de disco) debe tener la estructura de un sistema de archivos independiente que contenga su propia jerarquía de directorios . El efecto de mount es hacer que las referencias al archivo ordinario hasta ahora se refieran al directorio raíz del sistema de archivos en el volumen extraíble. En efecto, mount reemplaza una hoja del árbol de jerarquía (el archivo ordinario) por un subárbol completamente nuevo (la jerarquía almacenada en el volumen extraíble). Después del montaje, prácticamente no hay distinción entre los archivos en el volumen extraíble y los del sistema de archivos permanente. En nuestra instalación, por ejemplo, el directorio raíz reside en una pequeña partición de una de nuestras unidades de disco, mientras que la otra unidad, que contiene los archivos del usuario, está montada por la secuencia de inicialización del sistema. Un sistema de archivos montable se genera escribiendo en su archivo especial correspondiente. Un programa de utilidad está disponible para crear un sistema de archivos vacío, o uno simplemente puede copiar un sistema de archivos existente.

El sistema de archivos jerárquico también tiene la ventaja de concentrar la complejidad de administrar múltiples dispositivos de almacenamiento en el núcleo. Esto significaba que el núcleo era más complejo, pero como resultado todas las aplicaciones eran más simples. Dado que el núcleo tiene que preocuparse por los dispositivos de hardware, pero la mayoría de las aplicaciones no, este es un diseño más natural.

Ventanas

Windows remonta su ascendencia a dos linajes: VMS , un sistema operativo diseñado originalmente para la minicomputadora VAX , y CP / M , un sistema operativo diseñado para las primeras microcomputadoras Intel.

VMS tenía un sistema de archivos jerárquico distribuido, Archivos-11 . En Files-11, la ruta completa a un archivo contiene un nombre de nodo, una designación de cuenta en ese nodo, un nombre de dispositivo, una ruta de árbol de directorio, un nombre de archivo, un tipo de archivo y un número de versión. VMS tenía una poderosa función de nombre lógico que permitía definir accesos directos a directorios específicos, por lo que los usuarios rara vez tendrían que preocuparse por la ubicación "real" de un directorio.

CP / M fue diseñado para computadoras con 64kB de RAM y una unidad de disquete, por lo que fue por simplicidad. No había directorios, pero una referencia de archivo podría incluir una indicación de unidad ( A:o B:).

Cuando MS-DOS 2.0 introdujo directorios, lo hizo con una sintaxis compatible con MS-DOS 1 que seguía a CP / M. Entonces, las rutas se enraizaron en una unidad con un nombre de una sola letra. (Además, el carácter de barra diagonal /se usó en VMS y CP / M para iniciar las opciones de línea de comandos, por lo que se tuvo que usar un carácter diferente como separador de directorio. Esta es la razón por la cual DOS y Windows usan barra diagonal inversa, aunque algunos componentes internos también admiten barra diagonal )

Windows retuvo la compatibilidad con DOS y el enfoque VMS, por lo que mantuvo la noción de letras de unidad incluso cuando se volvieron menos relevantes. Hoy, bajo el capó, Windows usa rutas UNC ( desarrolladas originalmente por Microsoft e IBM para OS / 2 , de ascendencia relacionada). Aunque esto está reservado para usuarios avanzados (probablemente debido al peso del historial), Windows permite el montaje a través de puntos de análisis .

No hay problemas de seguridad detrás de tener un solo árbol de directorios.

Los chicos que diseñaron Unix tenían mucha experiencia con sistemas operativos que requerían que los usuarios supieran qué dispositivo físico contenía un recurso dado. Dado que parte del propósito de un sistema operativo es crear una máquina abstracta sobre hardware real, pensaron que era mucho más sencillo prescindir de los recursos de direccionamiento por su ubicación física y decidieron poner todo en un solo árbol de nombres.

Esta es solo una parte del genio detrás del diseño de Unix .

Tenga en cuenta que los nombres de letras de unidad de MS-DOS que persisten en Windows moderno son una pista falsa aquí. Los nombres de letras de unidad no son la mejor representación de una estructura de sistema de archivos que tiene múltiples raíces. Son una implementación de paja de tal sistema.

Un sistema de archivos implementado adecuadamente que admita múltiples raíces permitiría nombrar arbitrariamente los volúmenes, como dvdrom:/path/to/file.avi. Tal sistema eliminaría los ridículos problemas de la interfaz de usuario que afectan a Windows. Por ejemplo, si conecta un dispositivo como una cámara, la IU del Explorador de Windows le hace creer que hay un dispositivo llamado Cámara (o lo que sea), y que tiene una ruta similar Computer\Camera\DCIM\.... Sin embargo, si corta y pega la versión textual de esta ruta fuera del Explorador, en realidad no funciona porque algunos de los componentes de la ruta son una ficción de interfaz de usuario, no conocida por el sistema operativo subyacente. EN un sistema implementado adecuadamente con múltiples raíces, estaría bien: habría uncamera:\DCIM\...ruta que se reconoce de manera uniforme en todos los niveles del sistema. Además, si portabas un viejo disco duro desde una PC ANTIGUA, no estarías atascado con algún nombre de letra de unidad F:, sino que podrías nombrarlo como quieras old-disk:.

Por lo tanto, si Unix tuviera múltiples raíces en la estructura del sistema de archivos, se haría de una manera sensata, y no como en MS-DOS y Windows con nombres de unidades de una letra. En otras palabras, comparemos solo el esquema Unix con un buen diseño de múltiples raíces.

Entonces, ¿por qué Unix no tiene una implementación sensata de múltiples raíces, a favor de una implementación sensata de una raíz? Probablemente sea solo por simplicidad. Los puntos de montaje proporcionan toda la funcionalidad de poder acceder a los volúmenes a través de nombres. No es necesario ampliar el espacio de nombres con una sintaxis de prefijo adicional.

Matemáticamente hablando, cualquier gráfico de árbol disjunto ("bosque") se puede unir agregando un nodo raíz y haciendo que las piezas disjuntas sean sus hijos.

Además, es más flexible que los volúmenes no tengan que estar en el nivel raíz. Como no hay una sintaxis especial que denote el volumen (es solo un componente de ruta), los puntos de montaje pueden estar en cualquier lugar. Si trae en tres discos viejos a su máquina, puede tenerlos como /old-disk/one, /old-disk/two, etc. Puede organizar los discos que le apetezca, la forma de organizar los archivos y directorios.

Se pueden escribir aplicaciones que dependen de las rutas, y la validez de las rutas se puede mantener cuando se reconfiguran los dispositivos de almacenamiento. Por ejemplo, las aplicaciones pueden usar rutas conocidas como /var/logy /var/lib. Depende de usted si está /var/logy /var/libestá en el mismo volumen de disco o en uno separado. Puede migrar un sistema a una nueva topología de almacenamiento, mientras conserva las rutas.

Los puntos de montaje son una buena idea, por eso Windows los ha tenido desde Windows 2000.

Los puntos de montaje de volumen son sólidos frente a los cambios del sistema que ocurren cuando se agregan o eliminan dispositivos de una computadora. Microsoft Technet

Tanto * nix como Windows montan sus unidades. En Windows, estos se montan automáticamente en puntos de montaje que, de forma predeterminada, están en orden alfabético ascendente. Estos valores predeterminados son:

• A:y B:=> disquetes
• C: => primera partición del primer disco duro
• D: => siguiente partición o siguiente disco duro o unidad de CD / DVD si no hay otras particiones presentes.

Cada uno de estos puntos de montaje es un directorio.

En * nix, el usuario decide los puntos de montaje. Por ejemplo, tengo una partición montada como /y otra como /home. Entonces, /homees una unidad separada, sería el equivalente de decir E:en Windows.

En ambos casos, Windows y * nix, los puntos de montaje son directorios separados. La única diferencia es que en * nix, estos directorios separados son subdirectorios de /, C:mientras que en Windows, cada punto de montaje se monta directamente debajo de /, My Computerdigamos.

Desde la perspectiva del usuario, la principal ventaja es que las monturas son completamente transparentes. No necesito saber que el directorio /homeestá realmente en una partición separada. Solo puedo usarlo como un directorio normal. En cambio, en DOS, tendría que llamarlo explícitamente por el nombre del punto de montaje, digamosE:\home

Las unidades externas se montan prácticamente de la misma manera en ambos sistemas. Digamos D:para Windows y /mnt/cdrompara Linux. Cada uno de estos es un directorio, realmente no veo la diferencia. Cuando coloca un CDROM en su unidad bajo Windows, el disco se monta D:exactamente igual que en Linux.

Estoy de acuerdo con las respuestas anteriores, especialmente la respuesta de Doug O'Neal, pero creo que todos pierden algo, al igual que los puntos de montaje de dispositivos explícitos como MS-DOS "C:" o "A:".

Rob Pike escribió The Hideous Name sobre la sintaxis de los nombres, pero Russ Cox lo resumió :

Los espacios de nombres ... son más potentes cuando se pueden agregar nuevas semánticas sin agregar una nueva sintaxis.

Un espacio de nombre único donde los dispositivos se pueden montar arbitrariamente permite operaciones realmente flexibles. Regularmente uso /mnt/sdb1y /mnt/cdromcoloco temporalmente un disco o CD no utilizado actualmente en el sistema de archivos general. No es raro tener directorios de inicio en un servidor NFS, por lo que no importa en qué máquina inicie sesión, obtendrá lo mismo en $HOMEtodas partes.

Todo se reduce a esto: tener una sintaxis especial para cosas especiales pone límites definidos a lo que puede hacer. Si solo puede montar un disco o CD o DVD no utilizado, o un sistema de archivos de red / "compartir" en "E:" o "W:" o lo que sea, tendrá mucha menos flexibilidad.

Esto es tonto. Windows también tiene un único punto de jerarquía. Pero está oculto y no es estándar. Como la mayoría de las cosas de windows.

En este caso, es el concepto "Mi PC". Ese es el equivalente de root (/) en Unix. Recuerde que root es un concepto que existe en el kernel. Te gusta o no. Al igual que las ventanas tratan el "Mi PC". por supuesto, puedes montar una partición en root en unix, y eso es lo que hace la mayoría de la gente. Y muchas cosas mirarán una ruta específica para las cosas (por ejemplo, / etc /) pero no está limitado por ella. Por supuesto, monte sus unidades en / C: /. No está prohibido hacer eso en Unix.

C: \ no es una raíz en Windows, es el punto de montaje de una partición. Que DEBE estar en el nivel superior "Mi PC". Mientras esté en Unix, puede montar una partición debajo de cualquier otro árbol. Entonces, Linux puede tener C: montado /mientras tiene D: montado /mnt/d/... o incluso también montado, /pero eso es complicado y depende de cómo se comporten los dos sistemas de archivos al montar encima de una ruta ya montada.

Por lo tanto, puede obtener exactamente lo mismo que tiene con Windows al "forzarse" a seguir las mismas limitaciones que Windows le impone al azar.

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

Entonces tendría que pasar las opciones de montaje en las opciones de arranque. ya que no tendrás un / etc / ... pero eso también es simular las limitaciones que impone Windows, ya que eso es lo que hace.

La razón por la cual Windows tiene letras de unidad probablemente se remonta más allá de Microsoft y DOS. La asignación de letras a unidades extraíbles era común en los sistemas de IBM, por lo que Microsoft puede haber estado actuando según las instrucciones de IBM copiando CP / M. E inicialmente, DOS no tenía directorios de todos modos.

Cuando MS-DOS se ejecutaba en computadoras con uno o dos discos extraíbles y sin medios fijos, realmente no necesitaba un sistema de archivos con directorios. Con uno, o tal vez dos, discos de 180 kilobytes, nunca tuvo suficientes archivos para tener muchos problemas para organizarlos.

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

En realidad, Linux se basa en Unix (o es Unix, ver discusión ) y Unix proviene del entorno de mainframe, donde el uso de múltiples dispositivos era bastante obvio. El montaje de dispositivos en un solo árbol de directorios le brinda la máxima flexibilidad y no limita la cantidad de dispositivos a los que puede acceder el sistema operativo.

Por otro lado, las letras DOS para unidades son un buen diseño para una PC con 1 o 2 estaciones de disquete y una unidad de disco individual. El disquete grande 5,25 'siempre es A :, el pequeño 3,5' siempre es B :, y la unidad de disco siempre es C :. Siempre sabe si copia un archivo en el disquete o en algún lugar del disco. No necesita ninguna flexibilidad si no puede conectar físicamente más de 2 unidades de disquete y 2 (o 4) discos duros.

El diseño de DOS fue más amigable para el usuario final, mientras que el diseño de Unix es amigable para el administrador. Ahora las letras de unidad son una carga para Windows, los usuarios confían más en abrir automáticamente la ventana del explorador con contenido de unidad extraíble que saber su letra ... Ubuntu hace lo mismo, en realidad.

Eso no es cierto, en realidad. Windows usa otro esquema de rutas (bueno, no el mismo)

Las "Cartas de unidad" son solo algo para recordar fácilmente rutas, discos y particiones.

Las rutas ARC definen la ruta de un archivo en Windows (pero solo son visibles para el usuario en el arranque):

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

En Windows NT no hay relación entre discos, particiones y letras de unidad: puede "poner" un volumen completo en una carpeta (por ejemplo: c: \ myseconddisk podría ser un disco físico completo).

Dos cosas que me gustaría señalar:

1. Los discos duros en Linux están realmente asignados a letras / nombres, como / dev / sdb1. Pero se pueden montar en cualquier lugar para llegar desde la estructura única / raíz
2. La razón más común por la que las personas (incluyéndome a mí mismo en el pasado) tenían unidades separadas en Windows era tener un lugar para guardar documentos, música, programas, etc. falla del sistema de archivos, todavía había acceso a esos archivos. No tengo este problema en Linux: el sistema de archivos es mucho más confiable, el sistema operativo no se rompe a menos que sea por alguna acción directa o error de mi parte (¡ooh! ¡Un repositorio de última generación, intentemos eso!) Y actualizaciones son MUCHO más simples. Y, en el raro caso que tuve que reinstalar, ya que todo el software estaba disponible a través de repos o ppa's que agregué (y podía copiar fácilmente mi directorio de inicio con un disco en vivo),

Si mira hacia atrás en el historial, también puede ver que Unix comenzó en el momento de los sistemas de cintas de 8 pistas para audio y los sistemas de datos de IBM de 9 pistas (8 pistas / 8 bits para datos, uno para paridad). Técnicamente muy similar.

En ese momento, la información sobre la ubicación de los archivos se almacenaba en partes de la información en cinta y se definía hacia adelante y hacia atrás cuando se leían datos de la cinta (como un archivo, con posición inicial y firma final); también le explica por qué no tenía solo una FAT al comienzo de la unidad, sino que tenía varias para acelerar la búsqueda. Y si tenía varias unidades, estaban vinculadas dentro de / dev y a través de la dirección del archivo que movía entre los dispositivos.

Creo que podría tener la opinión de que comenzó simplemente antes y que la decisión detrás del área MS Dos (CP / M) y más tarde Windows NT simplemente está relacionada con las letras de unidad de mainframe VM en lugar de un solo punto de entrada porque en ese momento parecía más moderno, las cantidades de datos de hoy no existían y no pensaron que eventualmente terminaría sin tener suficientes letras de unidad o que estaría demasiado desordenado.

9-Track-Drive y asignación de letra de unidad