Si mount --bind
/a
entro /b
y si mv /a/bigfile /b/
lo hago, tomará mucho tiempo (si el archivo fuente es grande). En realidad, esto copiará el archivo y luego eliminará el archivo fuente en lugar de simplemente actualizar la tabla de archivos del sistema de archivos.
Entiendo cómo y por qué mount --bind
funciona. Como han señalado otros, hay algunas buenas explicaciones al respecto:
- ¿Qué es una montura de enlace?
- ¿Por qué no puedo crear un 'vínculo físico' a un archivo desde un directorio 'mount --bind' en el mismo sistema de archivos?
¿Hay alguna manera de decirle a mount que a mount --bind
está en el mismo sistema de archivos para que operaciones como esta (mover) se realicen actualizando la tabla de archivos del sistema de archivos?
Estoy preguntando cómo resolver este problema y no cómo entenderlo: tal vez ya hay un parche del kernel disponible que no conozco o un parámetro faltante que no encontré (etc.).
Por qué: en mi configuración actual hay un servicio (nextcloud) que solo admite mount --bind
. No puedo usar enlaces simbólicos. Si necesito, digamos, tener una carpeta compartida dentro de cada cuenta de nextcloud, debe ser con enlace. Puedo aceptar cualquier solución que funcione con nextcloud si está hecha en el nivel del sistema de archivos/kernel. Esto se debe a que la configuración actual también incluye acceso a estos archivos de otras formas, como ssh. En otras palabras, me gustaría poder mover un archivo como en el ejemplo usando cualquier comando o aplicación.
Respuesta1
Aparentemente no, elpágina de manualrename(2)
menciona esto:
EXDEV
viejo caminoynuevo caminono están en el mismo sistema de archivos montado. (Linux permite montar un sistema de archivos en múltiples puntos, perorename()
no funciona en diferentes puntos de montaje, incluso si el mismo sistema de archivos está montado en ambos.
Si no recuerdo mal, un montaje de enlace es lo mismo que simplemente montar el mismo sistema de archivos varias veces, es decir, no hay "origen" ni "destino" para el enlace después del hecho.
También hay otrorespuestaa otra pregunta sobre el mismo tema de hace un par de meses. Éste tiene sugerencias para una discusión al respecto con los desarrolladores del kernel. Así que vota eso.
Respuesta2
Tengo el mismo problema con nextcloud y samba en contenedores Docker. Lo resolví moviendo todos los datos dentro de nextcloud y dejé que otros los montaran desde este volumen.
entonces, desde el punto de vista de cualquier servicio, un mv siempre está dentro de un solo soporte de enlace.
Aunque no estoy seguro si esto te ayuda
Respuesta3
Usarlo rsync
en su lugar mv
debería resolver el problema. Intente usar el siguiente comando
rsync -avP /a/bigfile /b/bigfile
El problema se debe a que el punto de vista de mount --bind
está en el kernel y está oculto a programas de nivel superior como mv
. A diferencia de mv
, rsync
mueve únicamente las partes modificadas de un archivo.
Esto explica sobremount --bind
¿Qué es una montura de enlace?