Eliminar archivos lleva demasiado tiempo

11

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.

Antonis Christofides
fuente
1
2.5 millones de archivos en un solo directorio? No conozco un sistema de archivos que maneje esto bien.
Michael Hampton
@MichaelHampton: no es plano, contiene directorios anidados. Agregué la palabra "recursivamente" en la breve descripción; Espero que esto lo aclare.
Antonis Christofides
1
¿Por qué está utilizando el truco del directorio de copia en escritura en un sistema de archivos de copia en escritura?
symcbean
@symcbean: ¿Quieres decir que el truco del enlace duro es redundante btrfs? Esto es posible, por supuesto, pero ¿crees que puede ser relevante? En este momento no recuerdo por qué decidí intentarlo btrfs.
Antonis Christofides
2
Ah, lo recuerdo ahora. Decidí cambiar a btrfsporque quería la compresión transparente. Ahora: rsnapshotusa enlaces duros. No tiene ninguna opción para no usar enlaces duros. Entonces, los enlaces duros se superponen con btrfsla funcionalidad de copiar y escribir, pero no puedo hacer mucho al respecto.
Antonis Christofides

Respuestas:

3

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.

Marc Stürmer
fuente
1
¿Cómo se define "conocido"? Había buscado mucho en la web y en vano, y nadie de los que participaron en esta discusión lo sabía. Pero, de todos modos, ahora me estoy alejando btrfs. Demasiado publicitado mientras su desarrollo parece estar tomando una eternidad.
Antonis Christofides
1
Bueno, por ejemplo, están las personas de CoreOS. Usaron aproximadamente Btrfs un año como sistema de archivos predeterminado hasta principios de 2015, donde cambiaron a Ext4 + Overlayfs. Sin embargo, tenga en cuenta que esto fue antes de la versión 3.19 del kernel, que trajo muchas mejoras para Btrfs. También eche un vistazo a esta presentación de octubre de 2015, que echa un vistazo a ext4, xfs, zfs y btrfs en las condiciones de carga de trabajo de la base de datos, a saber, Postgres: de.slideshare.net/fuzzycz/… Otro punto de referencia, aunque no tan bueno kernel: goo.gl/rR3kZ2
Marc Stürmer
Y como dije, se sabe que la versión de kernel de su caja (3.16) está plagada de problemas de rendimiento, al menos use 3.19 para cosas Btrfs graves según Chris Mason. Si quiere usar Btrfs en serio, use siempre el núcleo más reciente y mejor, algo que no funciona muy bien con Debian ... y busque el término "rendimiento de metadatos btrfs".
Marc Stürmer el
2

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.

Nicolas Noble
fuente
0

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.

Nathan
fuente