Intenté acostarme. Si bien es bueno (y tiene algunas características diferenciadas útiles que pueden convertirlo en la mejor opción para muchos), parece escanear la totalidad de todos los archivos de destino en busca de sumas de verificación.
Lo cual es dolorosamente lento.
Otros programas, por otro lado, como rdfind y rmlint, escanean de manera diferente.
rdfind tiene una función "experimental" para usar btrfs reflink. (Y opciones "sólidas" para enlaces duros, enlaces simbólicos, etc.)
rmlint tiene opciones "sólidas" para btrfs clone, reflink, enlaces duros regulares, enlaces simbólicos, eliminar y sus propios comandos personalizados.
Pero lo más importante, rdfind y rmlint son significativamente más rápidos. Como en, órdenes de magnitud. En lugar de escanear todos los archivos de destino en busca de sumas de verificación, hace esto, aproximadamente:
- Escanee todo el sistema de archivos de destino, reuniendo solo rutas y tamaños de archivos.
- Eliminar de la consideración, archivos con tamaños de archivo únicos. Esto solo, ahorra tiempo y actividad de disco. ("Scads" es una función exponencial inversa o algo así).
- Del resto de candidatos, escanee los primeros N bytes. Elimine de la consideración, aquellos con los mismos tamaños de archivo pero diferentes primeros N bytes.
- Haga lo mismo para los últimos N bytes.
- Solo de ese resto (generalmente una pequeña fracción) restante, busque sumas de verificación.
Otras ventajas de rmlint que conozco:
- Puede especificar la suma de verificación. MD5 demasiado miedo? Prueba sha256. O 512. O comparación bit por bit. O tu propia función hash.
- Te da la opción de Btrfs "clonar" y "reflink", en lugar de solo reflink. "cp --reflink = always" es un poco arriesgado, ya que no es atómico, no sabe qué más está sucediendo para ese archivo en el kernel, y no siempre conserva los metadatos. "Clonar", OTOH (que es un término abreviado ... Estoy en blanco con el nombre oficial relacionado con la API), es una llamada a nivel de núcleo que es atómica y conserva los metadatos. Casi siempre resulta en lo mismo, pero un poco más robusto y seguro. (Aunque la mayoría de los programas son lo suficientemente inteligentes como para no eliminar el archivo duplicado, si no puede hacer un enlace temporal con éxito al otro).
- Tiene un montón de opciones para muchos casos de uso (que también es un inconveniente).
Comparé rmlint con deduperemove, que también escanea ciegamente todos los archivos de destino en busca de sumas de verificación. Duperemove tardó varios días en completar mi volumen (4 creo), yendo a toda velocidad. fmlint tomó algunas horas para identificar duplicados, luego menos de un día para deducirlos con el clon Btrfs.
(Dicho esto, cualquiera que haga el esfuerzo de escribir y respaldar software robusto y de calidad y regalarlo de forma gratuita, ¡merece un gran reconocimiento!)
Por cierto: debe evitar la deducción utilizando enlaces duros regulares como una solución de deducción "general", a toda costa.
Si bien los enlaces duros pueden ser extremadamente útiles en ciertos casos de uso específicos (por ejemplo, archivos individuales o con una herramienta que puede escanear en busca de tipos de archivos específicos que excedan un tamaño mínimo, o como parte de muchas soluciones de copias de seguridad / instantáneas gratuitas y comerciales), puede ser desastroso para "deduplicación" en un gran sistema de archivos de uso general. La razón es que la mayoría de los usuarios pueden tener miles de archivos en su sistema de archivos, que son binarios idénticos, pero funcionalmente completamente diferentes.
Por ejemplo, muchos programas generan plantillas y / o archivos de configuración ocultos (a veces en cada carpeta que puede ver), que inicialmente son idénticos, y la mayoría lo siguen siendo, hasta que usted, el usuario, necesite que no lo estén.
Como ilustración específica: los archivos de caché de miniaturas de fotos, que innumerables programas generan en la carpeta que contiene las fotos (y por una buena razón: portabilidad), pueden tardar horas o días en generarse, pero luego hacen que usar una aplicación de fotos sea muy fácil. Si esos archivos de caché iniciales están todos vinculados, luego abre la aplicación en un directorio y crea un caché grande ... luego adivine qué: ahora CADA carpeta que tiene un caché previamente vinculado, ahora tiene el caché incorrecto. Potencialmente, con resultados desastrosos que pueden provocar la destrucción accidental de datos. Y también potencialmente de una manera que explota una solución de respaldo que no es compatible con enlaces duros.
Además, puede arruinar instantáneas enteras. El objetivo de las instantáneas es que la versión "en vivo" pueda seguir cambiando, con la posibilidad de volver a un estado anterior. Sin embargo, si todo está unido ... se "retrocede" a lo mismo.
Sin embargo, la buena noticia es que deducir con Btrfs clone / reflink, puede deshacer ese daño (creo, ya que durante el escaneo, debería ver los archivos enlazados como idénticos ... a menos que tenga lógica para no considerar los enlaces duros. Probablemente depende de la utilidad específica que realiza la deducción)