¿Por qué cp --reflink = auto no es el comportamiento predeterminado?

¿Por qué cp --reflink=autono es el comportamiento predeterminado? ¿Podría causar algún daño habilitarlo?

¿Es posible habilitarlo en tiempo de compilación, por lo que se usa en todo el sistema, no solo en shells interactivos?

No es el valor predeterminado, ya que, por razones de robustez, es posible que desee una copia para proteger contra la corrupción de datos. También, por razones de rendimiento, es posible que desee que las escrituras se realicen en el momento de la copia en lugar de que algún proceso sensible a la latencia trabaje en un archivo CoW y se retrase posiblemente por las escrituras en una parte diferente de un disco mecánico. Tenga en cuenta que desde coreutils v8.24 mv se vinculará de forma predeterminada, ya que no tiene las restricciones anteriores.

No sé por qué no es el valor por defecto, tal vez de modo que se comporta igual que otras utilidades de copia ( rsync, cpio, pax, tar...) que no tienen soporte para el mismo (o cuando se copian archivos de una interfaz que no permite que (como NFS, samba, capas de sistemas de archivos fusibles ...).

Estuve en la misma situación hace unos años, y mirando el código GNU cp rápidamente, sigue siendo el mismo, tienes que parchear el código para obtener un comportamiento predeterminado diferente:

--- coreutils-8.21/src/cp.c~    2013-06-22 21:50:26.265639114 +0100
+++ coreutils-8.21/src/cp.c     2013-06-22 21:51:06.880513924 +0100
@@ -775,7 +775,7 @@ cp_option_init (struct cp_options *x)
   x->interactive = I_UNSPECIFIED;
   x->move_mode = false;
   x->one_file_system = false;
-  x->reflink_mode = REFLINK_NEVER;
+  x->reflink_mode = REFLINK_AUTO;

   x->preserve_ownership = false;
   x->preserve_links = false;

Un gran problema es la posibilidad de quedarse sin espacio para hacer la copia cuando escribe.

Con una copia normal, tan pronto como se complete la copia, nunca tendrá que preocuparse por una falla en la escritura en partes existentes del archivo: el espacio está completamente asignado y no desaparecerá hasta que elimine el archivo. Pero con una copia de reflink, siempre existe el riesgo de que en algún momento semanas o meses en el futuro, una escritura en una parte existente del archivo falle porque no hay suficiente espacio para hacer una copia.

Descubrir que su sistema había estado haciendo copias de reflink a sus espaldas cuando una operación como esa falló sería una sorpresa bastante desagradable.

alias cp='cp --reflink=auto --sparse=always'

tiene más sentido que parchear el código

1. Razones de robustez uno puede desear una copia para proteger contra la "pérdida" de datos.

   No sabemos esa es la razón, pero las cosas malas que pueden suceder se limitan a la destrucción de los medios. La mayoría de los dispositivos de bloque tendrán algún tipo de identificación de corrupción (crc), si no reenvían la corrección de errores (paridad).

2. No por razones de rendimiento.

   ¿La vaca ocurre cuando solo una parte del? Borrado? el bloque está escrito en. Con moderno! Disco! dispositivo el tamaño del bloque de hardware es un múltiplo de 4k. Cambiar parte del 4k hace que la unidad lea todo el 4k y lo vuelva a escribir, pero además el núcleo hará lo mismo, por lo que no habrá ninguna escritura parcial que llegue al dispositivo de bloque, SSD o de otro modo . El kernel necesita realizar el programa de trabajo por las mismas razones, a menos que tengamos una copia en caché, no podemos inventar los datos que existen en las otras partes del dispositivo, salvo el final de un archivo, pero el punto es discutible. Pero el almacenamiento en caché de una copia de un archivo y la copia de un archivo varían en diferentes operaciones, la primera es mucho más barata.

   La dirección de la escritura es irrelevante, pero tenga en cuenta que "alguna parte no utilizada del dispositivo" es más barata de descubrir que "dónde residen actualmente los bloques del archivo".

El hecho es que cualquier método CoW es más barato o igual que simplemente actualizar un dispositivo de bloque. Ahora, si no estuviéramos hablando de dispositivos de bloque, entonces sería otra historia ... Escrito en cinta en alguna parte.