¿Por qué necesitamos montar en Linux?

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

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

mount /dev/cdrom /media/cdrom

Estamos montando el dispositivo CDROM /media/cdromy eventualmente podemos acceder a los archivos de 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í es como está diseñado Linux ". Pero si es así, ¿por qué fue diseñado de esa manera? ¿Por qué no acceder al /dev/cdromdirectorio directamente? ¿Cuál es el verdadero propósito del montaje?

Una razón es que el acceso a nivel de bloque es un nivel un poco más bajo de lslo que sería capaz de trabajar. /dev/cdrom, o dev/sda1puede ser su unidad de CD ROM y la partición 1 de su disco duro, respectivamente, pero no están implementando ISO 9660 / ext4, son solo punteros RAW a los dispositivos conocidos como Archivos de dispositivo .

Una de las cosas que Mount determina es CÓMO usar ese acceso sin procesar: qué módulos de lógica / controlador / kernel del sistema de archivos administrarán las lecturas / escrituras, o traducirán ls /mnt/cdromen 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 lo suficientemente bueno; Acabo de leer y escribir en puertos serie, dispositivos usb, terminales tty y otros dispositivos relativamente simples. Nunca trataría de leer / escribir manualmente desde / dev / sda1 para, por ejemplo, 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 (tal vez) o, en su lugar, escribir todo esto en el diario, demasiado difícil.

Una forma de ver esto por sí 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 núcleo ofrece como un "identificador" para ese dispositivo.

Vea la entrada de wikipedia en Archivos de dispositivo para un tratamiento más profundo.

Básicamente, y para decirlo fácilmente, el sistema operativo necesita saber cómo acceder a los archivos en ese dispositivo.

mount no solo "le da acceso a los archivos", le dice 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 lssaber qué archivos (si los hay) están en ¿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.

Por consistencia

Imagine que tiene algunas particiones en el primer disco duro de su sistema. Por ejemplo, /dev/sda2. Más tarde decide que la unidad no es lo suficientemente grande, por lo que compra una segunda y la agrega al sistema. De repente, eso se convierte /dev/sday su unidad actual se convierte /dev/sdb. Tu partición es ahora /dev/sdb2.

Usando su sistema propuesto, tendría que cambiar todos los scripts, aplicaciones, configuraciones, etc. que acceden a los datos en su partición anterior para reflejar este cambio en los nombres.

Sin embargo, el montaje le permite seguir utilizando el mismo punto de montaje para esta unidad renombrada. Tendría que editar /etc/fstabpara decirle a su sistema que (por ejemplo) /media/backupahora está en su /dev/sdb2lugar, pero esa es solo una edición.

Tenga en cuenta que los sistemas modernos son aún más fáciles. En lugar de hacer referencia al dispositivo como /dev/sda2o /dev/sdb2, tienen UUIDS, que se parecen c5845b43-fe98-499a-bf31-4eccae14261bo se pueden dar etiquetas más amigables, como las backupque se pueden usar para hacer referencia al dispositivo durante el montaje. De esta manera, el nombre del dispositivo no cambia al agregar un nuevo dispositivo, lo que hace que la administración sea aún más simple:

# mount LABEL="backup" /media/backup

Por seguridad

Al requerir que se monte un dispositivo, el administrador puede controlar el acceso al dispositivo. El dispositivo se puede quitar cuando se desmonta, pero no cuando está en uso (a menos que desee sufrir una pérdida de datos). Si eres (eras) un usuario de Windows, ¿recuerdas el pequeño ícono verde en el área de notificación que te dice que es seguro quitar una memoria USB? Es el montaje y desmontaje de Windows para usted. Entonces el principio no es solo de Unix / Linux.

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

Compare Windows: Windows comenzó como un sistema operativo para 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, sin nada. (Windows 3.11 tenía capacidades de red nativas; Windows 3.1 no ).

El tipo de configuración en el que nació Windows fue 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.

En contraste, 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 entidad única y uniforme para los usuarios finales, sin importar cuántas computadoras se distribuyeran los discos físicos, sin importar qué tipo de disco, y sin importar cuál de las docenas de computadoras el usuario accedería desde La ruta lógica a los archivos del usuario permanecería igual, incluso si la ubicación física de esos archivos hubiera cambiado durante la noche, 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 es host / 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ía cuenta.
(A diferencia de la convención de Windows de dar diferentes nombres a diferentes dispositivos físicos - C :, D :, etc. - que funciona en contra de la transparencia que Unix estaba buscando).

En ese tipo de entorno, no puedes simplemente montar todo a la vista de cualquier manera,

En una red grande, los discos individuales y las computadoras están fuera de servicio constantemente. Los administradores necesitan la capacidad de decir qué está montado dónde y cuándo, por ejemplo, hacer un apagado controlado de una computadora mientras otra computadora se encarga de alojar los mismos archivos de manera transparente.

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

• 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é está montado dónde y cuándo.
• Windows nació en un entorno donde no había administrador y solo 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 de una sola computadora, por supuesto, pero también fue diseñado explícitamente desde el principio para imitar a Unix lo más fielmente posible en una computadora doméstica).

Más recientemente, los sistemas operativos se han acercado 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 configuraciones de una sola computadora.
• Windows ha agregado más seguridad, redes, soporte para múltiples usuarios, etc .; a medida que las redes se hicieron más ubicuas y Microsoft comenzó a crear un sistema operativo para servidores también.

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

Hay varias ventajas en la disposición actual. Se pueden agrupar en ventajas de archivos especiales de bloque y ventajas de puntos de montaje.

Los archivos especiales son archivos que representan dispositivos. Una de las ideas sobre las que se creó Unix es que todo es un archivo. Esto simplifica muchas cosas, por ejemplo, la interacción del usuario es solo lectura y escritura de archivos en un dispositivo tty, que es un archivo especial de caracteres. Del mismo modo, verificar si hay bloques defectuosos, particionar o formatear un disco son solo operaciones de archivo. No importa si el disco es mfm, ide, scsi, fiberchanel o algo más, es solo un archivo.

Pero, por otro lado, es posible que no desee tratar con todo el disco o la partición solo con los archivos y, en muchos casos, con más archivos de los que caben en un disco. Entonces tenemos puntos de montaje. Un punto de montaje le permite colocar un disco completo (o partición) en un directorio. En mis días de Slackware, cuando un disco duro de buen tamaño tenía un par de cientos de MB, era común usar el CD como / usr y el disco duro para /, / usr / local e intercambiar. O puede poner / en un disco y / home en otro.

Ahora me di cuenta de que mencionaste montar tu CD en / media / cdrom, que es útil para computadoras con una sola unidad cdrom, pero ¿qué pasa si tienes más de una? ¿Dónde deberías montar el segundo? o el tercero? o el decimoquinto? ciertamente podría usar / media / cdrom2, etc. O podría montarlo en / src / samba / resources / windows-install, o / var / www, o donde tenga sentido hacerlo.

El título de la pregunta es: ¿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: nosotros no.

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

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

Una segunda interpretación: ¿Por qué a veces necesitamos emitir mountcomandos explícitos para que los sistemas de archivos estén disponibles en Linux? ¿Por qué no hacer que el sistema operativo siempre lo haga 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 el contenido del CD-ROM en la lista?

Presumiblemente, quieres decir: ¿por qué no hacer que ese comando haga lo que

ls /media/cdrom

hace ahora?

Bueno, en ese caso, /dev/cdromsería un árbol de directorios, no un archivo de dispositivo. Entonces, su 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 use un CD-ROM o cualquier otro dispositivo que almacene archivos, se utiliza un software que interpreta lo que está en su CD-ROM como un árbol de directorios de archivos. Se invoca cada vez que utiliza lso cualquier otro tipo de comando o aplicación que accede a los archivos en 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 enumere, lea o escriba archivos en un sistema de archivos, el trabajo de ese software es asegurarse de que las operaciones de lectura y escritura de bajo nivel correspondientes se realicen en el dispositivo en cuestión. Cada vez que tiene mountun sistema de archivos, le está diciendo qué controlador de sistema de archivos debe usar para el dispositivo. Si haces esto explícitamente con unmountcomando, o dejar que el sistema operativo se 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 un 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 dispositivos son la abstracción común de bajo nivel para dispositivos. Se supone que el software realmente específico del dispositivo (el controlador del dispositivo) para un dispositivo particular implementa la apertura, cierre, lectura y 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 que estén de acuerdo en una forma común de interactuar entre sí, y para eso están los archivos del dispositivo.

Por lo tanto, los controladores del sistema de archivos necesitan los archivos del dispositivo.

Pero, ¿por qué nosotros, los usuarios comunes, 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 dispositivo y controladores de sistema de archivos. De hecho, así es como se escriben.

Lo mismo es cierto para 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 aparece una nueva pieza de hardware en el mercado, o se diseña una nueva forma más inteligente de implementar un sistema de archivos , alguien puede escribir el código para admitirlo, hacerlo funcionar y contribuir a Linux.

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

Muchos motores de bases de datos pueden trabajar directamente con discos sin formato o particiones. Por ejemplo, MySQL:

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

Esto evita la sobrecarga de pasar por los controladores del sistema de archivos, cuando todo lo que el motor de base de datos realmente necesita es un archivo enorme que llene el disco.

Porque /dev/cdromes un dispositivo, mientras que /media/cdromes un sistema de archivos . Debe montar el primero en el segundo para acceder a los archivos en el CD-ROM.

Su sistema operativo ya está montando automáticamente los sistemas de archivos raíz y de usuario desde su dispositivo de disco duro físico, cuando inicia su computadora. Esto es solo agregar más sistemas de archivos para usar.

Todos los sistemas operativos hacen esto; sin embargo, algunos (como Windows, cuando monta un CD-ROM D:) lo hacen de manera transparente. Linux te lo deja a ti para que tengas un mayor control sobre el proceso.

Lo hace porque existe, con muchos medios para las IU de computadoras de escritorio y portátiles, ambigüedad sobre qué hacer cuando se inserta el medio, porque la intuición del usuario es que insertar el disco en la caja física con la que interactúa el usuario no es diferente, por ejemplo. , insertándolo en un dispositivo al lado de la computadora que tiene una conexión de red.

Por lo tanto, en el sentido fundamental, la interfaz de usuario para los medios debe tratar los dos tipos de eventos de montaje potenciales de manera similar, y no hay una buena manera para que las computadoras manejen los montajes de red de la manera más intuitiva posible para los montajes de red con otras UI a las computadoras, como teléfonos inteligentes, tabletas y computadoras portátiles, que carecen de la posibilidad de insertar medios físicos en los dispositivos. (Tenga en cuenta lo horrible que es la interfaz de iPhone para cambiar las tarjetas SIM, el único tipo de medios físicos que los dispositivos iOS han insertado en ellas.

Tenga en cuenta también que otros enfoques populares de las IU para este tipo de cuadro físico (por ejemplo, Windows 98, Windows 8, Mac OS X v10.2 (Jaguar) y Mac OS X v10.9 (Mavericks)) se encuentran con los mismos problemas y use cuadros de diálogo de GUI adicionales para resolver la posible confusión (por ejemplo, Windows 8 generalmente está configurado para solicitar cada nuevo CD insertado, ya sea que deba montarse como un sistema de archivos, un medio de música o, si corresponde, una colección de videos MP4 ) No hay ninguna razón por la cual ninguno de estos cuadros de diálogo de usuario se pueda usar con Linux u otros UNIX.