¿Hay algún inconveniente al usar mount --bind como sustituto de enlaces simbólicos?

Enlaces simbólicos tienen limitaciones en la forma en funciones como ls, mvy cppueden funcionar en ellos porque comandos iniciados shell diferencia gusta cd, estas funciones no tienen información sobre cómo el usuario accede al directorio con respecto a la trayectoria lógica (ver relacionada poste ). Parece que usar la mount --bindopción en su lugar puede evitar esto, ofreciendo una mayor funcionalidad y compatibilidad con samba y otros servidores de archivos porque el directorio montado tendrá dos rutas físicas independientes, en lugar de un enlace.

Me gustaría reemplazar todos mis enlaces simbólicos con referencias usando la mount --bindopción, pero esto significaría montar más de 150 puntos en fstab. ¿Hay algún problema de rendimiento que pueda surgir de este o cualquier otro inconveniente que deba considerar?

Con mount --bind, existe un árbol de directorios en dos (o más) lugares en la jerarquía de directorios. Esto puede causar varios problemas. Las copias de seguridad y otras copias de archivos seleccionarán todas las copias. Se hace difícil especificar que desea copiar un sistema de archivos: terminará copiando los archivos montados en enlace dos veces. Las búsquedas con find, grep -r, locate, etc, atravesarán todas las copias, y así sucesivamente.

No obtendrá ninguna "mayor funcionalidad y compatibilidad" con los montajes de enlace. Se parecen a cualquier otro directorio, que la mayoría de las veces no es un comportamiento deseable. Por ejemplo, Samba expone enlaces simbólicos como directorios por defecto; no hay nada que ganar con el uso de un montaje de enlace. Por otro lado, los montajes de enlace pueden ser útiles para exponer jerarquías de directorios a través de NFS.

No tendrá problemas de rendimiento con los montajes de enlace. Lo que tendrá es dolores de cabeza de administración. Los montajes de enlace tienen sus usos, como hacer que un árbol de directorios sea accesible desde un chroot, o exponer un directorio oculto por un punto de montaje (generalmente es un uso transitorio mientras se está remodelando una estructura de directorio). No los use si no los necesita.

Solo root puede manipular montajes de enlace. No se pueden mover por medios ordinarios; bloquean su ubicación y los directorios de antepasados.

En términos generales, si pasa un enlace simbólico a un comando, el comando actúa en el enlace en sí mismo si funciona en archivos, y en el destino del enlace si funciona en el contenido del archivo. Esto también se aplica a los directorios. Esto suele ser lo correcto. Algunos comandos tienen opciones a los enlaces simbólicos a tratar de manera diferente, por ejemplo ls -L, cp -d, rsync -l. Independientemente de lo que intente hacer, es mucho más probable que los enlaces simbólicos sean la herramienta correcta, en lugar de que los montajes de enlace sean la herramienta correcta.

Además de lo que @Gilles escribió anteriormente, vale la pena señalar que algunas utilidades podrían considerar un directorio montado en un enlace como un sistema de archivos separado. Esto puede tener implicaciones de rendimiento o funcionalidad si el programa ya no puede suponer que el mismo número de inodo se refiere al mismo archivo (lo que no ocurre, si están en diferentes sistemas de archivos), un movimiento no puede optimizarse como enlace en target-then-unlink-source, etc.

También debe usar montajes de enlace en lugar de enlaces simbólicos cuando confía en un soporte que puede no estar siempre en su lugar (por ejemplo, un disco externo) y desea asegurarse de que la estructura de directorios original esté en su lugar, incluso si el soporte falla o se elimina.

Por ejemplo, si quiero mantener / var / tmp en una tarjeta SD, usaré el montaje de enlace, ya que algunos programas esperarán que / var / tmp sea un directorio válido incluso si se quita la tarjeta.

Intenté bind mount para solucionar un problema al instalar algunos paquetes con pacman(archlinux, más sobre eso aquí ) en un sistema donde /var(así como /homey /usr/local) eran enlaces simbólicos (a través de sistemas de archivos: SSD a SATA).

Al principio se veía genial, pero, como señaló Gilles, locatesiempre daba múltiples resultados para un solo archivo, a pesar de la PRUNE_BIND_MOUNTS = "yes"línea /etc/updatedb.conf.

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

Excavando un poco más, descubrí que los montajes de unión más complejos se pueden podar correctamente:

$ sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

Sin la opción PRUNE_BIND_MOUNT, habría obtenido 3 resultados:

$ sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ sudo sed -i '1 s/no/yes/' /etc/updatedb.conf 

Otro problema con los montajes de enlace:

• grub-mkrelpath produce rutas incorrectas si / boot es un montaje de enlace

Por supuesto, se puede añadir manualmente montaje de vínculos (mounpoint u objetivo) a PRUNEPATHSen /etc/updatedb.conf.

Además, se pueden usar mountpointvarios statcomandos o funciones en herramientas para mejorar el recorrido del sistema de archivos como se propone aquí

Cuando se trata de montajes de enlace de archivo, se comportan más cerca de los enlaces duros que de los enlaces simbólicos. Esto puede tener consecuencias algo sutiles, por ejemplo:

# echo 1 > 1.txt
# touch 2.txt
# mount --bind 1.txt 2.txt
# cat 2.txt
1
# echo 1a > 1.txt
# cat 2.txt
1a

Hasta ahora todo bien, pero ahora considere cuántos programas (editores, scripts escritos correctamente, etc.) realmente modifican los archivos:

# echo 1new > 1new.txt
# mv 1new.txt 1.txt
# cat 1.txt
1new
# cat 2.txt
1a

Si 2.txthubiera sido un enlace simbólico 1.txt, el último comando tendría salida 1new, que es lo que probablemente se esperaría.

Esto puede causar algunos problemas sutiles: en lo systemd se utiliza BindReadOnlyPaths=para hacer un uso determinado servicio de un diferente resolv.confarchivo que el resto del sistema, pero que resultó ser escamosa en raro y difícil de diagnosticar maneras, porque resolvconfsería reemplazar el archivo de origen detrás de la El servicio ha vuelto.