Espero poder responder esto de una manera que tenga sentido para usted. Un sistema de archivos en Linux generalmente está compuesto por una partición que está formateada en una de varias formas (¡hay que elegir el amor!) En la que almacena sus archivos. Ya sea que sus archivos del sistema, o sus archivos personales ... todos estén almacenados en un sistema de archivos. Esta parte pareces entender.
Pero, ¿qué pasa si particiona su disco duro para tener más de una partición (piense en Apple Pie cortado en pedazos), o agrega un disco duro adicional (tal vez una memoria USB?). En aras de la discusión, todos ellos también tienen sistemas de archivos.
Cuando mira los archivos en su computadora, está viendo una representación visual de los datos en el sistema de archivos de su partición. Cada nombre de archivo corresponde a lo que se llama un inodo, que es donde realmente viven sus datos, detrás de escena. Un enlace duro le permite tener múltiples "nombres de archivo" (a falta de una mejor descripción) que apunten al mismo inodo. Esto solo funciona si esos enlaces duros están en el mismo sistema de archivos. En cambio, un enlace simbólico apunta al "nombre de archivo", que luego se vincula al inodo que contiene sus datos. Perdona mi obra de arte cruda, pero espero que esto explique mejor.
image.jpg image2.jpg
\ /
[your data]
aquí, image.jpg e image2.jpg apuntan directamente a sus datos. Ambos son enlaces duros. Sin embargo...
image.jpg <----------- image2.jpg
\
[your data]
En este ejemplo (crudo), image2.jpg no apunta a sus datos, apunta a image.jpg ... que es un enlace a sus datos.
Los enlaces simbólicos pueden funcionar a través de los límites del sistema de archivos (suponiendo que el sistema de archivos esté conectado y montado, como su memoria USB). Sin embargo, un enlace duro no puede. No sabe nada sobre lo que hay en su otro sistema de archivos o dónde se almacenan sus datos.
Esperemos que esto ayude a tener más sentido.
chroot(2)contenedorización real, puede tener múltiples jerarquías, que pueden no tener nada que ver entre sí.chrootaísla una parte de la jerarquía de un proceso y sus descendientes, pero el padre todavía tiene una jerarquía completa. La contenedorización puede hacerlo, dependiendo de qué tan cerca de una VM esté. Pero, ¿cuántos detalles se pueden incluir en un comentario? Gracias,El sistema de archivos está compuesto por una estructura de directorio compuesta por entradas de directorio para organizar archivos. Cada entrada de directorio asocia un nombre de archivo con un inodo .
Los enlaces blandos ( simbólicos ) son entradas de directorio que no contienen datos, solo apunta a otra entrada (un archivo o directorio en el mismo sistema de archivos u otro sistema de archivos). Y cuando elimina el archivo señalado, el enlace simbólico queda inutilizable.
Los enlaces duros son entradas de directorio que contienen el nombre del archivo y el número de inodo . Cuando elimina el último enlace duro, ya no puede acceder al archivo.
Conclusión:
Como el inodo es una estructura de datos utilizada para representar un objeto del sistema de archivos, es interno del sistema de archivos y no puede apuntar a un inodo de otro sistema de archivos.
Por lo tanto, los enlaces duros solo son válidos dentro del mismo sistema de archivos, pero los enlaces blandos (enlace simbólico) pueden abarcar sistemas de archivos, ya que simplemente apuntan a otra entrada de directorio (la interfaz del sistema de archivos y no un objeto interno).
fuente
/mnt/myfile. Si monta otro sistema de archivos en/mnt/. El enlace suave se resolvería en una entrada del sistema de archivos montado en/mnt/. Por lo tanto, si montó el sistema de archivos desde su dispositivo USB/mnt, el enlace flexible se resolvería en una entrada en ese sistema de archivos.El sistema de archivos raíz puede estar compuesto por varios sistemas de archivos;
/usr/localpodría estar montado en una partición separada y/homepodría estar en otra partición en un disco en red en otro lugar. En este caso, un enlace rígido para/usr/local/bin/git(por ejemplo) puede no crearse fuera de/usr/local, porque abarcaría los sistemas de archivos .La razón de esto es que los inodes se asignan por separado para
/,/usr/localy/home(nuevamente, en este ejemplo), y cuando crea un enlace duro, realmente solo crea un nombre adicional para un inodo.fuente
Los enlaces duros tienen el efecto de mantener vivo a su objetivo. Siempre que se pueda acceder a cualquier enlace duro, el sistema se asegurará de que su objetivo no pueda liberarse. Por lo tanto, es necesario que todos los medios que puedan contener enlaces duros a un inodo particular se monten cada vez que el sistema intente determinar si existen referencias a él.
Dado que la vida útil del inodo generalmente se determina manteniendo recuentos de referencias en lugar de buscar referencias, podría ser posible organizar cosas para que dos o más sistemas de archivos que contienen enlaces entre sí se puedan usar de forma independiente siempre que no haya necesidad de usar enlaces que puenteado entre los sistemas, y siempre que no haya necesidad de usar fsck en ninguno de los dos. Sin embargo, si se altera el recuento de inodes en uno de los sistemas, la única forma de hacer que ese sistema sea útil nuevamente sería utilizar una forma de operación fsck que pudiera escanear ambos sistemas de archivos en busca de referencias. Debido a esa restricción, si bien es posible permitir que dos sistemas de archivos interconectados se puedan usar de forma independiente, los beneficios de hacerlo probablemente serían demasiado limitados para que valga la pena.
fuente
Un solo número de inodo se utiliza para representar el archivo en cada sistema de archivos. Todos los enlaces duros basados en el número de inodo. Enlace de referencia del sistema de archivos aquí .
fuente