¿Por qué rm es lento en una unidad de almacenamiento externa (conectada por USB, tipo fuseblk) con 50 Gb de archivos?

21

He estado tratando de usar rsnapshot para hacer copias de seguridad, pero lo encuentro inutilizable. Si bien es capaz de diferenciar un directorio (50 gb) y duplicarlo (vincular cada archivo) en unos minutos, y puedo copiar todo el directorio en aproximadamente media hora, toma más de una hora eliminarlo. Incluso usando directamente rm -rfv, encuentro que puede tomar hasta medio segundo para ejecutar un solo archivo, mientras que los comandos cpy se linkcompletan instantáneamente.

¿Por qué es tan lento? ¿Hay alguna forma más rápida de eliminar recursivamente los enlaces duros? No tiene sentido para mí que copiar un archivo debería tomar menos tiempo que eliminarlo.

El sistema de archivos en el que estoy trabajando es una unidad de almacenamiento externa, conectada a través de usb y tipo fuseblk (que creo que significa que es ntfs). Mi computadora está ejecutando ubuntu linux.

Salida desde arriba:

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers

performance rm external-hdd

— Benubird
fuente

1

Estar montado como fuseblkno significa que el disco es NTFS, solo significa que está montado como un dispositivo de bloque FUSE. Eso podría ser casi cualquier cosa.

— Chris Down

1

@ChrisDown True, pero sé que es NTFS o ext3, y estoy bastante seguro de que si fuera ext3, se montaría como tal por mount sin argumentos.

— Benubird

1

Depende de cuántos archivos hay en el directorio (no dijo cuántos), y en particular NTFS se ralentiza con solo> 3K archivos en el directorio. Casi cualquier otro sistema de archivos es mucho más eficiente. Vea todas las otras publicaciones en SO / SE sobre el efecto del número de archivos en el rendimiento del sistema de archivos.

— smci

28

En última instancia, no importa lo que haga, rmdebe ejecutarse unlinken cada archivo que desee eliminar (incluso si llama rm -ral directorio principal). Si hay muchos archivos para eliminar, esto puede llevar mucho tiempo.

Hay dos procesos que requieren mucho tiempo cuando ejecuta rm -r:

readdir, seguido por,
una serie de llamadas a unlink.

Encontrar todos los archivos, y luego revisar cada archivo para eliminarlo, puede llevar mucho, mucho tiempo.

Si encuentra esto "inutilizable" porque hace que el directorio quede inutilizable durante algún tiempo, considere mover el directorio principal antes de eliminarlo. Esto liberará ese nombre para que el programa lo use nuevamente, sin que el tiempo sea demasiado inconveniente.

Suponiendo que el sistema de archivos realmente es NTFS (no está claro en su pregunta), NTFS generalmente es bastante lento para eliminar grandes extensiones de archivos. Puede considerar usar un sistema de archivos más adecuado para sus propósitos (los sistemas de archivos ext más recientes tienen un rendimiento de eliminación bastante bueno, si no tiene otras necesidades particulares). FUSE en sí tampoco es particularmente rápido, en general. Puede considerar ver si puede hacer esto de alguna manera que no use FUSE.

— Chris Down
fuente

2

+1 Mucho depende del sistema de archivos exacto: muchos tienden a funcionar realmente bien para algunas operaciones y son lentos con otras (a menudo esto es para la creación de archivos frente a la eliminación frente al acceso a datos).

— Peter

15

¿Por qué es tan lento? No tengo idea. Pero sí conozco una forma más rápida:

mkdir blank
rsync -a --delete blank/ test/

Actualización: esta respuesta en Serverfault tiene algunas explicaciones. Parece que rsync está eliminando los archivos en un orden particular que hace que el árbol del sistema de archivos permanezca equilibrado y nunca necesite un reequilibrio. rm simplemente eliminará los archivos y causará mucho reequilibrio a medida que se eliminen. Hay algo de información sobre el reequilibrio de aquí .

— rjmunro
fuente

1

¿Has comparado esto y comparado con rm -rf? rsynctodavía tiene unlink()todos los archivos test/, y eso es probablemente lo que toma el tiempo.

— MattBianco

No lo he comparado formalmente, pero lo intenté después de leer los puntos de referencia de otra persona, y la diferencia fue sustancial. Ya no puedo encontrar esa publicación, pero esta respuesta en serverfault tiene una explicación y una fuente para un programa de eliminación aún más rápido.

— rjmunro

Pero el método más rápido debe estar unlink(2)en el directorio (y recordar hacer fsckmás tarde) ...

— MattBianco

Un hecho es un hecho. Solo lo cronometré y es casi el doble de rápido. Después de leer el código rm de GNU coreutils, ni siquiera me hace preguntarme ...

— Dominik George

1

Bueno, una vez tuve un problema similar con el tuyo. Descubrí que tu "wa" es alta, podrías usar

iostat -x 1

verificar si la utilidad de su disco es alta, si es así, significa que su disco está bastante ocupado. Verifique si algunos otros procesos están escribiendo en el disco continuamente.

Por simplicidad, use

vmstat 1

para verificar si b es alto o r < b . Eso indica que algo anda mal. En su situación, creo que el disco io es la razón original.

— fibonacci
fuente