¿Por qué necesitamos montar en Linux?

Question

Entiendo qué es el montaje en Linux y entiendo los archivos de dispositivo. Sin embargo, no entiendo POR QUÉ necesitamos montar.

Por ejemplo, como se explica en elrespuesta aceptada de esta pregunta, usando este comando:

mount /dev/cdrom /media/cdrom

Estamos montando el dispositivo CDROM /media/cdromy finalmente podemos acceder a los archivos del CDROM con el siguiente comando.

ls /media/cdrom

que enumerará el contenido del CDROM.

¿Por qué no omitir el montaje por completo y hacer lo siguiente?

ls /dev/cdrom

Y tenga el contenido del CDROM listado. Espero que una de las respuestas sea: "Así está diseñado Linux". Pero si es así, ¿por qué se diseñó de esa manera? ¿Por qué no acceder al /dev/cdromdirectorio directamente? ¿Cuál es el verdadero propósito del montaje?

Answer 1

Una razón es que el acceso a nivel de bloque es un nivel un poco más bajo del que lssería posible trabajar. /dev/cdrom, o dev/sda1puede ser su unidad de CD ROM y la partición 1 de su disco duro, respectivamente, pero no implementan ISO 9660/ext4; son solo punteros RAW a esos dispositivos conocidos comoArchivos de dispositivo.

Una de las cosas que el montaje determina es CÓMO usar ese acceso sin formato: qué lógica del sistema de archivos/controlador/módulos del kernel administrarán las lecturas/escrituras, o traducirán ls /mnt/cdroma qué bloques deben leerse, y cómo interpretar el contenido de esos. bloques en cosas como file.txt.

Otras veces, este acceso de bajo nivel puede ser suficiente; Acabo de leer y escribir en puertos serie, dispositivos USB, terminales tty y otros dispositivos relativamente simples. Nunca intentaría leer/escribir manualmente desde /dev/sda1 para, digamos, editar un archivo de texto, porque básicamente tendría que volver a implementar la lógica ext4, que puede incluir, entre otras cosas: buscar los inodos del archivo, encontrar el bloques de almacenamiento, leer el bloque completo, hacer mis cambios, escribir los bloques completos, luego actualizar el inodo (quizás), o en su lugar escribir todo esto en el diario, demasiado difícil.

Una forma de comprobarlo usted mismo es simplemente probarlo:

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

/devEs un directorio, y puedes cdy lstodo lo que quieras. /dev/sda1no es un directorio; es un tipo especial de archivo que es lo que el kernel ofrece como 'identificador' para ese dispositivo.

Verla entrada de wikipedia sobre archivos de dispositivopara un tratamiento más profundo.

Answer 2

Básicamente, y para decirlo de forma sencilla, el sistema operativo necesita saber cómo acceder a los archivos de ese dispositivo.

mountno solo "le da acceso a los archivos", sino que le indica al sistema operativo el sistema de archivos que tiene la unidad, si es de solo lectura o acceso de lectura/escritura, etc.

/dev/cdromes un dispositivo de bajo nivel, las funciones del sistema operativo no sabrían cómo acceder a ellas... imagina que pones un cdrom con un formato extraño (incluso un cd de audio), ¿cómo sabrías lsqué archivos (si los hay) están allí? el cd-rom sin "montarlo" primero?

Tenga en cuenta que esto sucede automáticamente en muchos sistemas operativos (incluso Linux en algunas distribuciones e interfaces gráficas), pero eso no significa que otros sistemas operativos no estén "montando" las unidades.

Answer 3

Yo lo llamaría razones históricas. No es que las otras respuestas sean incorrectas, pero hay un poco más en la historia.

Compare Windows: Windows comenzó como un sistema operativo de una sola computadora y un solo usuario. Esa única computadora probablemente tenía una unidad de disquete y un disco duro, sin conexión de red, sin USB, nada de nada. (Windows 3.11 tenía capacidades de red nativas;Windows 3.1 no.)

El tipo de configuración en la que nació Windows era tan simple que no había necesidad de ser sofisticado: simplemente monte todo (los dos dispositivos) automáticamente cada vez, no hay (no hubo) muchas cosas que pudieran salir mal.

Por el contrario, Unix fue creado para ejecutarse en redes de servidores con múltiples usuarios desde el principio.

Una de las decisiones de diseño de Unix fue que el sistema de archivos debería aparecer como una única entidad uniforme para los usuarios finales, sin importar en cuántas computadoras estuvieran distribuidos los discos físicos, sin importar qué tipo de disco y sin importar en cuál de las docenas de computadoras estuvieran distribuidos. desde donde el usuario accedería. La ruta lógica a los archivos del usuario permanecería igual, incluso si la ubicación física de esos archivos hubiera cambiado de la noche a la mañana, por ejemplo, debido al mantenimiento del servidor.

Estaban abstrayendo el sistema de archivos lógico, las rutas a los archivos, de los dispositivos físicos que almacenaban esos archivos. Digamos que el servidor A normalmente aloja /home, pero el servidor A necesita mantenimiento: simplemente desmonte el servidor A y monte el servidor de respaldo B en /home, y nadie, aparte de los administradores, se dará cuenta.
(A diferencia de la convención de Windows de dar diferentes nombres a diferentes dispositivos físicos - C:, D:, etc. - que va en contra de la transparencia por la que Unix se esforzaba).

En ese tipo de escenario, no puedes simplemente montar todo lo que esté a la vista quieras o no,

En una red grande, los discos individuales y las computadoras están constantemente fuera de servicio. Administradoresnecesidadla capacidad de decir qué se monta, dónde y cuándo, por ejemplo, realizar un apagado controlado de una computadora mientras otra computadora se hace cargo de alojar de manera transparente los mismos archivos.

Por eso, desde una perspectiva histórica: Windows y Unix provienen de orígenes diferentes. Podrías llamarlo una diferencia cultural, si quieres:

• Unix nació en un entorno donde el administrador necesitaba controlar el montaje; De las docenas de dispositivos de almacenamiento en la red, el administrador debe decidir qué se monta, dónde y cuándo.
• Windows nació en un entorno donde no había administrador y sólo dos dispositivos de almacenamiento, y el usuario probablemente sabría si su archivo estaba en el disquete o en el disco duro.
• (Linux nació como un sistema operativo para una sola computadora, por supuesto, pero también fue diseñado explícitamente desde el principio para imitar lo más posible a Unix en una computadora doméstica).

Más recientemente, los sistemas operativos se han ido acercando entre sí:

• Linux ha agregado más cosas para una sola computadora y un solo usuario (como el montaje automático); ya que se utilizó con frecuencia en entornos de una sola computadora.
• Windows ha agregado más seguridad, redes, soporte para múltiples usuarios, etc.; a medida que las redes se volvieron más omnipresentes y Microsoft también comenzó a crear un sistema operativo para servidores.

Pero aún así es fácil decir que los dos son el resultado de tradiciones diferentes.

Answer 4

El título de la pregunta pregunta:¿Por qué necesitamos montar en Linux?

Una forma de interpretar esta pregunta:¿Por qué necesitamos emitir mountcomandos explícitos para que los sistemas de archivos estén disponibles en Linux?

La respuesta: no lo hacemos.

No necesita montar sistemas de archivos explícitamente, puede hacer que se haga automáticamente, y las distribuciones de Linux ya lo hacen para la mayoría de los dispositivos, tal como lo hacen Windows y Mac.

Entonces probablemente eso no es lo que querías preguntar.

Una segunda interpretación:Porque nosotrosa veces¿Necesita emitir mountcomandos explícitos para que los sistemas de archivos estén disponibles en Linux? ¿Por qué no crear el sistema operativo?siempre¿Hacerlo por nosotros y ocultarlo al usuario?

Esta es la pregunta que estoy leyendo en el texto de la pregunta, cuando preguntas:

¿Por qué no omitir el montaje por completo y hacer lo siguiente?

ls /dev/cdrom

¿Y tiene listado el contenido del CD-ROM?

Probablemente querrás decir: ¿por qué no hacer que ese comando haga lo que

ls /media/cdrom

¿ahora?

Bueno, en ese caso, /dev/cdromsería un árbol de directorios, no un archivo de dispositivo. Entonces tu verdadera pregunta parece ser: ¿por qué tener un archivo de dispositivo en primer lugar?

Me gustaría agregar una respuesta a las ya dadas.

¿Por qué los usuarios pueden ver los archivos del dispositivo?

Siempre que utiliza un CD-ROM, o cualquier otro dispositivo que almacene archivos, se utiliza un software que interpreta lo que hay en su CD-ROM como un árbol de directorios de archivos. Se invoca cada vez que utiliza lscualquier otro tipo de comando o aplicación que acceda a los archivos de su CD-ROM. Ese software es el controlador del sistema de archivos para el sistema de archivos particular utilizado para escribir los archivos en su CD-ROM. Siempre que enumera, lee o escribe archivos en un sistema de archivos, el trabajo de ese software es asegurarse de que las correspondientes operaciones de lectura y escritura de bajo nivel se realicen en el dispositivo en cuestión. Cada vez que utiliza mountun sistema de archivos, le está indicando al sistema qué controlador de sistema de archivos usar para el dispositivo. Ya sea que haga esto explícitamente con un mountcomando o deje que el sistema operativo lo haga automáticamente, será necesario hacerlo y, por supuesto, el software del controlador del sistema de archivos deberá estar allí en primer lugar.

¿Cómo hace su trabajo un controlador de sistema de archivos? La respuesta: lo hace leyendo y escribiendo en el archivo del dispositivo. ¿Por qué? La respuesta, como ya dijiste: Unix fue diseñado de esta manera. En Unix, los archivos de dispositivo son la abstracción común de bajo nivel para los dispositivos. Se supone que el software realmente específico del dispositivo (el controlador del dispositivo) para un dispositivo en particular implementa la apertura, el cierre, la lectura y la escritura en el dispositivo como operaciones en el archivo del dispositivo. De esa manera, el software de nivel superior (como un controlador de sistema de archivos) no necesita saber tanto sobre el funcionamiento interno de los dispositivos individuales. Los controladores de dispositivo de bajo nivel y los controladores del sistema de archivos pueden ser escritos por separado por diferentes personas, siempre y cuando estén de acuerdo en una forma común de interactuar entre sí, y para eso están los archivos de dispositivo.

Entonces, los controladores del sistema de archivos necesitan los archivos del dispositivo.

Pero ¿por qué nosotros, los usuarios comunes y corrientes, podemos ver los archivos del dispositivo? La respuesta es que Unix fue diseñado para ser utilizado por programadores de sistemas operativos. Fue diseñado para permitir a sus usuarios escribir controladores de dispositivos y controladores de sistemas de archivos. De hecho, así es como se escriben.

Lo mismo ocurre con Linux: puede escribir su propio controlador de sistema de archivos (o controlador de dispositivo), instalarlo y luego usarlo. Hace que Linux (o cualquier otra variante de Unix) sea fácilmente extensible (y de hecho es la razón por la que se inició Linux): cuando sale al mercado una nueva pieza de hardware, o se diseña una forma nueva y más inteligente de implementar un sistema de archivos. , alguien puede escribir el código para respaldarlo, hacerlo funcionar y contribuir con Linux.

Los archivos del dispositivo lo hacen más fácil.