¿Por qué mover archivos entre subvolúmenes btrfs es una operación costosa?

Por lo que entiendo, los subvolúmenes btrfs comparten el mismo "almacenamiento" del sistema de archivos, por lo que me sorprendió saber que mover archivos entre diferentes subvolúmenes es una operación costosa, como moverse entre diferentes sistemas de archivos (copiar + eliminar).

Me sorprendió especialmente cuando alguien sugirió esta solución alternativa: vuelva a copiar los archivos entre subvolúmenes y luego elimine los originales. Se dice que es una operación barata (solo se mueve alrededor de los metadatos). ¿Cómo es que diferentes subvolúmenes pueden compartir bloques de datos cuando se usa COW, pero no en la operación más fácil de mover datos?

file-transfer benchmarking btrfs

— m.alessandrini
fuente

Esto no responde a su pregunta, pero puede interesarle saber que desde coreutils 8.24 (lanzado el 3 de julio de 2015) en adelante, mvintentará un enlace de referencia antes de volver a una copia estándar ( registro de cambios ).

— Vincent Yu

@ VincentYu gracias por la información. ¿Pero una operación de mover / renombrar no debería ser administrada por el propio sistema de archivos, en lugar de las utilidades de espacio de usuario? Por lo que leí, este comportamiento de movimiento es el mismo incluso si se realiza dentro del mismo punto de montaje, es decir, no tener el subvolumen montado en otro directorio, por lo que el núcleo tal vez no pueda reconocer que es el mismo sistema de archivos.

— m.alessandrini

@VincentYu solo para información, y despertado por la nueva respuesta, intenté mover un archivo grande entre subvolúmenes con un sistema más actualizado (prueba de Debian, kernel 4.6.0, coreutils 8.25-2), pero nada cambió.

— m.alessandrini

@ m.alessandrini Me acabo de dar cuenta de que para poder usar cp --reflinkentre dos subvolúmenes me vi obligado a montar el subvolumen de nivel superior y emitir el cpcomando dentro de ese espacio de nombres , de lo contrario cpsaldría con un error que decía...Invalid cross-device link

— Dzamo Norton,

@DzamoNorton el hecho es que anteriormente no funcionaba incluso en la configuración que describe (todas las subdirecciones del directorio actual), donde funcionaba reflink-copy. Pero acabo de intentarlo y hoy el movimiento también es una operación de tiempo cero (kernel 4.16), así que supongo que esto se ha abordado.

— m.alessandrini

¿Cómo es que diferentes subvolúmenes pueden compartir bloques de datos cuando se usa COW, pero no en la operación más fácil de mover datos?

mv usa el cambio de nombre syscall para intentar el movimiento. El cambio de nombre de kernel de btrfs impl detecta el movimiento de subvolúmenes cruzados y lo rechaza explícitamente (incluso si está bajo el mismo punto de montaje):

/* we only allow rename subvolume link between subvolumes */
if (old_ino != BTRFS_FIRST_FREE_OBJECTID && root != dest)
    return -EXDEV;

Esto probablemente tiene que ver con la contabilidad de inodo de subvolumen y las rutas de código que toman estas operaciones. La copia de enlace de referencia en realidad está creando nuevos metadatos (pero los datos en sí mismos son CoW) contabilizados en el nuevo subvolumen. En teoría, probablemente podrían cambiar el nombre de "mover" los metadatos haciendo algo similar a lo que hace copia --reflink seguido de rm source ... simplemente nadie se ha esforzado por hacerlo.

— Will Brown
fuente

Gracias, hojeé el código del núcleo por curiosidad, y aparte de no entenderlo a primera vista (obviamente), realmente no entiendo esa oración en el comentario. ¿Sabes lo que puede significar?

— m.alessandrini

Los subvolúmenes aparecen como entradas de directorio (también conocido como "enlace de subvolumen") en cualquier parte del sistema de archivos. El comentario dice que solo puede cambiar el nombre (también conocido como mover) las entradas del directorio de subvolúmenes entre subvolúmenes y no directorios / archivos reales.

— Will Brown