Eliminar archivos lleva demasiado tiempo

Versión corta : rm -rf mydircon mydir(recursivamente) que contiene 2.5 millones de archivos, toma alrededor de 12 horas en una máquina en su mayoría inactiva.

Más información : La mayoría de los archivos que se eliminan son enlaces duros a archivos en otros directorios (el directorio que se está eliminando es en realidad la copia de seguridad más antigua realizada rsnapshot; el rmcomando en realidad está dado por rsnapshot). Por lo tanto, se eliminan principalmente las entradas de directorio: el contenido del archivo en sí no es mucho; está en el orden de algunas decenas de GB.

Estoy lejos de estar seguro de que ese btrfses el culpable. Recuerdo que la copia de seguridad también era muy lenta antes de comenzar a usarla btrfs, pero no estoy seguro de que la lentitud estuviera en la eliminación.

La máquina es un Intel Core i5 2.67 GHz con 4 GB de RAM. Tiene dos discos SATA: uno tiene el sistema operativo y algunas otras cosas, y el disco de respaldo es de 1 TB WDC WD1002FAEX-00Z3A0. La placa base es una Asus P7P55D.

Editar : La máquina es un debian wheezy con Linux 3.16.3-2~bpo70+1. Así es como se monta el sistema de archivos:

root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)

Editar : El uso rsync -a --delete /some/empty/dir mydirdura aproximadamente 6 horas. Una mejora significativa rm -rf, pero todavía creo que demasiado. (La explicación de por qué rsynces más rápido querm : "[M] ost filesystems almacena sus estructuras de directorio en un formato btree, el orden [en] en el que elimina los archivos es ... importante. Es necesario evitar reequilibrar el btree cuando realiza el desvinculación .... rsync -a --delete... borra en orden ")

Editar : adjunté otro disco que tenía 2,2 millones de archivos (recursivamente) en un directorio, pero en XFS. Aquí hay algunos resultados comparativos:

                  On the XFS disk      On the BTRFS disk
Cached reads[1]       10 GB/s               10 GB/s
Buffered reads[1]     80 MB/s              115 MB/s
Walk tree[2]         11 minutes            43 minutes
rm -rf mydir[3]       7 minutes            12 hours

[1] Con hdparm -T /dev/sdXy hdparm -t /dev/sdX.
[2] Tiempo que se tarda en ejecutarse find mydir -print|wc -linmediatamente después del arranque.
[3] En el disco XFS, esto fue poco después de recorrer el árbol con find. En el disco BTRFS es la medida anterior (y no creo que fuera con el árbol en caché).

Parece ser un problema con btrfs.

Bueno, esto sigue siendo un problema de Btrfs, es bien sabido que eliminar muchos archivos pequeños lleva bastante tiempo en comparación con otros sistemas de archivos.

Si no le gusta, puede esperar hasta que el flujo ascendente lo haya solucionado o pasar a otro sistema de archivos que lo haga mejor.

Sin embargo, su error principal es usar un kernel antiguo (3.16, sí, ya era antiguo cuando publicó) con btrfs. Btrfs es un sistema de archivos que todavía está en desarrollo, por lo que siempre debe permanecer con la última y mejor versión del kernel para ponerse en contacto con las mejoras. Si su distribución no tiene backports, puede hacerlo usted mismo o está jodido.

Btrfs obtuvo muchas mejoras de rendimiento en la versión 3.19 del kernel: esta es la versión mínima que debe usar en producción, su versión 3.16 del kernel simplemente apesta sin backports.

También tenga en cuenta que, según Chris Mason, considera que Btrfs es estable por ahora, pero aún no está listo para la producción.

Llego un poco tarde a esta fiesta, pero aquí hay un truco para eliminar muy rápidamente árboles btrfs extremadamente grandes:

1. Cree un subvolumen ficticio en el mismo sistema de archivos btrfs.
2. Mueva el directorio de nivel superior que desea eliminar a dicho subvolumen: esta operación debería ser realmente rápida si lo está haciendo en el mismo sistema de archivos btrfs, incluso en subvolúmenes.
3. Destruye el subvolumen.

El kernel comenzará a reclamar espacio en segundo plano, por lo que no tendrá el espacio disponible de inmediato, pero el proceso debería ser mucho más rápido que hacer cualquier tipo de borrado de usuario.

Puede cambiar el nombre del directorio y luego eliminar el directorio renombrado en un proceso en segundo plano. Esto no va a acelerar la operación de eliminación. Sin embargo, esto permitiría que el programa continúe hacia adelante con un directorio vacío mientras la operación de eliminación se realiza de forma lateral.

No estoy seguro de si esto va a funcionar en su caso de uso. Depende si el programa no puede continuar hasta que el disco esté inactivo (es decir, va a realizar algunas operaciones de disco pesado). Depende de si el programa va a llenar el disco con muchos datos.