Eliminar 10M + archivos de ZFS, efectivamente

He escrito un programa con errores que accidentalmente ha creado unos 30 millones de archivos en / tmp. (El error se introdujo hace algunas semanas y estaba creando un par de subdirectorios por segundo). Pude cambiar el nombre de / tmp a / tmp2, y ahora necesito eliminar los archivos. El sistema es FreeBSD 10, el sistema de archivos raíz es zfs.

Mientras tanto, una de las unidades en el espejo salió mal y la he reemplazado. La unidad tiene dos discos SSD de 120GB.

Aquí está la pregunta: reemplazar el disco duro y reactivar toda la matriz tomó menos de una hora. Eliminar archivos / tmp2 es otra historia. He escrito otro programa para eliminar los archivos, y solo puede eliminar 30-70 subdirectorios por segundo. Tardará entre 2 y 4 días en eliminar todos los archivos.

¿Cómo es posible que la recuperación de toda la matriz demore una hora, pero la eliminación del disco demore 4 días? ¿Por qué tengo tan mal desempeño? 70 eliminaciones / segundo parece muy, muy mal rendimiento.

Podría eliminar el inodo para / tmp2 manualmente, pero eso no liberará el espacio, ¿verdad?

¿Podría ser esto un problema con zfs, o los discos duros o qué?

Las eliminaciones en ZFS son caras. Más aún si tiene la desduplicación habilitada en el sistema de archivos (ya que desreferenciar archivos deducidos es costoso). Las instantáneas también podrían complicar las cosas.

Puede que sea mejor eliminar el /tmpdirectorio en lugar de los datos que contiene.

Si /tmpes un sistema de archivos ZFS, elimínelo y vuelva a crear.

¿Cómo es posible que la recuperación de toda la matriz demore una hora, pero la eliminación del disco demore 4 días?

Considere un edificio de oficinas.

Quitar todas las computadoras, muebles y accesorios de todas las oficinas en todos los pisos lleva mucho tiempo, pero deja las oficinas inmediatamente utilizables por otro cliente.

La demolición de todo el edificio con RDX es un conjunto mucho más rápido, pero el próximo cliente es muy probable que se quejan de lo corrientes de aire es el lugar.

Hay una serie de cosas que suceden aquí.

Primero, todas las tecnologías de disco modernas están optimizadas para transferencias masivas. Si necesita mover 100 MB de datos, lo harán mucho más rápido si están en un bloque contiguo en lugar de estar dispersos por todo el lugar. Las SSD ayudan mucho aquí, pero incluso prefieren los datos en bloques contiguos.

En segundo lugar, la recuperación es bastante óptima en lo que respecta a las operaciones de disco. Lees una gran cantidad de datos contiguos de un disco, haces algunas operaciones rápidas de la CPU y luego la reescribes en otra gran porción contigua a otro disco. Si la energía falla a la mitad, no es gran cosa: simplemente ignorará cualquier dato con sumas de verificación incorrectas y continuará como de costumbre.

Tercero, eliminar un archivo es realmente lento . ZFS es particularmente malo, pero prácticamente todos los sistemas de archivos tardan en eliminarse. Deben modificar una gran cantidad de diferentes fragmentos de datos en el disco y cronometrarlos correctamente (es decir, esperar) para que el sistema de archivos no se dañe si falla la alimentación.

¿Cómo es posible que la recuperación de toda la matriz demore una hora, pero la eliminación del disco demore 4 días?

La recuperación es algo en lo que los discos son realmente rápidos, y la eliminación es algo en lo que los discos son lentos. Por megabyte de disco, solo tiene que hacer un poco de recuperación. Es posible que tenga mil archivos en ese espacio que deben eliminarse.

70 eliminaciones / segundo parece muy, muy mal rendimiento

Depende. No me sorprendería esto. No ha mencionado qué tipo de SSD está usando. Los SSD modernos de Intel y Samsung son bastante buenos en este tipo de operación (lectura-modificación-escritura) y funcionarán mejor. Las SSD más baratas / antiguas (por ejemplo, Corsair) serán lentas. El número de operaciones de E / S por segundo (IOPS) es el factor determinante aquí.

ZFS es particularmente lento para eliminar cosas. Normalmente, realizará eliminaciones en segundo plano para que no vea el retraso. Si está haciendo una gran cantidad de ellos, no puede ocultarlo y debe retrasarlo.

Apéndice: ¿por qué las eliminaciones son lentas?

• Eliminar un archivo requiere varios pasos. Los metadatos del archivo deben marcarse como 'eliminados' y, finalmente, deben recuperarse para que el espacio pueda reutilizarse. ZFS es un 'sistema de archivos estructurado de registro' que funciona mejor si solo crea cosas, nunca las elimina. La estructura de registro significa que si elimina algo, hay un espacio en el registro y, por lo tanto, se deben reorganizar (desfragmentar) otros datos para llenar el espacio. Esto es invisible para el usuario pero generalmente lento.
• Los cambios deben hacerse de tal manera que si la energía fallara a mitad de camino, el sistema de archivos permanece consistente. A menudo, esto significa esperar hasta que el disco confirme que los datos realmente están en los medios; para un SSD, eso puede llevar mucho tiempo (cientos de milisegundos). El efecto neto de esto es que hay mucha más contabilidad (es decir, operaciones de E / S de disco).
• Todos los cambios son pequeños. En lugar de leer, escribir y borrar bloques flash completos (o cilindros para un disco magnético), necesita modificar un poco de uno. Para hacer esto, el hardware debe leer en un bloque o cilindro completo, modificarlo en la memoria y luego volver a escribirlo en los medios. Esto lleva mucho tiempo.

¿Cómo es posible que la recuperación de toda la matriz demore una hora, pero la eliminación del disco demore 4 días?

Es posible porque las dos operaciones funcionan en diferentes capas de la pila del sistema de archivos. El resilver puede ejecutarse a bajo nivel y en realidad no necesita mirar archivos individuales, copiando grandes cantidades de datos a la vez.

¿Por qué tengo tan mal desempeño? 70 eliminaciones / segundo parece muy, muy mal rendimiento.

Tiene que hacer mucha contabilidad ...

Podría eliminar el inodo para / tmp2 manualmente, pero eso no liberará el espacio, ¿verdad?

No sé para ZFS, pero si pudiera recuperarse automáticamente de eso, probablemente, al final, haría las mismas operaciones que ya está haciendo, en segundo plano.

¿Podría ser esto un problema con zfs, o los discos duros o qué?

¿ zfs scrubDice algo?

Eliminar muchos archivos nunca es realmente una operación rápida.

Para eliminar un archivo en cualquier sistema de archivos, debe leer el índice del archivo, eliminar (o marcar como eliminado) la entrada del archivo en el índice, eliminar cualquier otro metadato asociado con el archivo y marcar el espacio asignado para el archivo como no usado. Esto debe hacerse individualmente para cada archivo que se va a eliminar, lo que significa que eliminar muchos archivos requiere muchas E / S pequeñas. Hacer esto de una manera que asegure la integridad de los datos en caso de falla de energía agrega aún más sobrecarga.

Incluso sin las peculiaridades que presenta ZFS, la eliminación de 30 millones de archivos generalmente significa más de cien millones de operaciones de E / S separadas. Esto va a llevar mucho tiempo, incluso con un SSD rápido. Como otros han mencionado, el diseño de ZFS agrava aún más este problema.

Ian Howson da una buena respuesta sobre por qué es lento.

Si elimina archivos en paralelo, puede ver un aumento en la velocidad debido a que la eliminación puede usar los mismos bloques y, por lo tanto, puede guardar la reescritura del mismo bloque muchas veces.

Entonces intenta:

find /tmp -print0 | parallel -j100 -0 -n100 rm

y vea si eso funciona mejor que sus 70 eliminaciones por segundo.

Muy simple si inviertes tu pensamiento.

1. Obtenga una segunda unidad (parece que ya tiene esto)

2. Copie todo desde la unidad A a la unidad B con rsync, excluyendo el directorio / tmp. Rsync será más lento que una copia en bloque.

3. Reiniciar, usando la unidad B como el nuevo volumen de inicio

4. Vuelva a formatear la unidad A.

Esto también desfragmentará su unidad y le dará un nuevo directorio (bien, la desfragmentación no es tan importante con un SSD, pero la linealización de sus archivos nunca daña nada)

Tienes 30 millones de entradas en una lista sin ordenar. Escanea la lista en busca de la entrada que deseas eliminar y la eliminas. Ahora solo tiene 29,999,999 entradas en su lista sin ordenar. Si todos están en / tmp, ¿por qué no simplemente reiniciar?

Editado para reflejar la información en los comentarios: Declaración del problema: Eliminar la mayoría, pero no todos , de los más de 30 millones de archivos creados incorrectamente en / tmp está tomando mucho tiempo.
Problema 1) La mejor manera de eliminar grandes cantidades de archivos no deseados de / tmp.
Problema 2) Comprender por qué es tan lento eliminar archivos.

Solución 1) - / tmp se restablece a vacío en el arranque por la mayoría de las distribuciones * nix. FreeBSD sin embargo, no es uno de ellos.
Paso 1: copie archivos interesantes en otro lugar.
Paso 2 - Como root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Paso 3: reinicia.
Paso 4: cambie clear_tmp_enable de nuevo a "No".
Los archivos no deseados ahora se han ido ya que ZFS en FreeBSD tiene la función de que "Destruir un conjunto de datos es mucho más rápido que eliminar todos los archivos que residen en el conjunto de datos, ya que no implica escanear todos los archivos y actualizar todos los metadatos correspondientes. " así que todo lo que tiene que hacer en el momento del arranque es restablecer los metadatos para el conjunto de datos / tmp. Esto es muy rapido.

Solución 2) ¿Por qué es tan lento? ZFS es un maravilloso sistema de archivos que incluye características tales como acceso al directorio de tiempo constante. Esto funciona bien si sabe lo que está haciendo, pero la evidencia sugiere que el OP no es un experto en ZFS. El OP no ha indicado cómo intentaban eliminar los archivos, pero supongo que diría que usaron una variación en "find regex -exec rm {} \;". Esto funciona bien con números pequeños pero no se escala porque hay tres operaciones en serie en curso 1) obtener la lista de archivos disponibles (devuelve 30 millones de archivos en orden hash), 2) usar expresiones regulares para elegir el siguiente archivo que se eliminará, 3 ) le dice al sistema operativo que busque y elimine ese archivo de una lista de 30 millones. Incluso si ZFS devuelve una lista de la memoria y si 'find' lo almacena en caché, la expresión regular todavía tiene que identificar el siguiente archivo que se procesará de la lista y luego decirle al sistema operativo que actualice sus metadatos para reflejar ese cambio y luego actualice la lista para que no se procese nuevamente.