Oh sí. Si ejecuta ln -s
, crea un enlace simbólico, que es un inodo que apunta a un determinado objeto del sistema de archivos, razón por la cual los enlaces simbólicos pueden atravesar sistemas de archivos y los enlaces duros no pueden: los enlaces duros no tienen su propio inodo.
Si monta un sistema de archivos con --bind
, crea un segundo punto de montaje para un dispositivo o sistema de archivos.
Si visualiza un enlace simbólico como una redirección, visualice un --bind
sistema de archivos montado como creando otra puerta de enlace a los datos.
Los enlaces simbólicos y las monturas de unión son un juego de pelota completamente diferente.
El --bind
montaje me parece un poco más robusto y probablemente sea un poco más rápido que trabajar con un enlace simbólico. Por otro lado, no hay inconvenientes serios al usar el enlace simbólico, ya que el impacto en el rendimiento será pequeño (si es que existe).
Editar : He estado pensando en esto, y el éxito en el rendimiento podría ser un poco más grande de lo que pensé originalmente. Si tiene una aplicación que lee muchos archivos diferentes, cada nuevo archivo que se abra requerirá una lectura adicional. Algunas investigaciones aquí sugieren que mi suposición es correcta, por lo que si tiene una aplicación pesada de IO ejecutándose allí, considere la --bind
opción de montar por encima de la solución de enlace simbólico.
La razón por la que no es común, es probablemente el hecho de que un enlace simbólico es visible en un ls
, mientras que un montaje de enlace solo es visible cuando se mira / proc / mounts o / etc / mtab (que es lo que hace el comando de montaje, si es ejecutado sin parámetros). Aparte de eso, no creo que haya ningún problema. Sin embargo, me interesaría si los hay.
Además : otro problema ln -s
es que para algunas aplicaciones, cuando la ruta se desreferencia, puede hacer que la aplicación se resista si "espera" que ciertos elementos estén en lugares específicos.