Escribí un ratarmount alternativo más rápido , que "funciona para mí", porque este problema me seguía molestando.
Puedes usarlo así:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
Cuando haya terminado, puede desmontarlo como cualquier montaje FUSE:
fusermount -u mount-folder
¿Por qué es más rápido que archivemount?
Depende de lo que midas.
Aquí hay un punto de referencia de la huella de memoria y el tiempo requerido para el primer montaje, así como los tiempos de acceso para un cat <file-in-tar>comando simple y un findcomando simple .
Se crearon carpetas que contenían cada uno de los archivos 1k y la cantidad de carpetas varía.
La gráfica inferior izquierda muestra barras de error que indican los tiempos medidos mínimo y máximo cat <file>para 10 archivos elegidos al azar.
Tiempo de búsqueda de archivo
La comparación asesina es el tiempo que lleva cat <file>terminar. Por alguna razón, esto se escala linealmente con el tamaño del archivo TAR (aprox. Bytes por archivo x número de archivos) para el montaje en archivo, mientras que es de tiempo constante en ratarmount. Esto hace que parezca que archivemount ni siquiera admite la búsqueda en absoluto.
Para archivos TAR comprimidos, esto es especialmente notable.
cat <file>toma más del doble de tiempo que montar todo el archivo .tar.bz2. Por ejemplo, el TAR con 10k archivos vacíos (!) Tarda 2.9 segundos en montarse con archivemount, pero dependiendo del archivo al que se accede, el acceso cattoma entre 3 ms y 5 segundos. El tiempo que lleva parece depender de la posición del archivo dentro del TAR. Los archivos al final del TAR tardan más en buscarse; indicando que la "búsqueda" se emula y todos los contenidos en el TAR antes de que se lea el archivo.
Que obtener el contenido del archivo puede llevar más del doble de tiempo que montar todo el TAR es inesperado en sí mismo. Al menos, debe terminar en la misma cantidad de tiempo que el montaje. Una explicación sería que el archivo se está buscando de forma emulada más de una vez, tal vez incluso tres veces.
Aparentemente, Ratarmount tarda siempre la misma cantidad de tiempo en obtener un archivo porque admite la búsqueda real. Para los TAR comprimidos de bzip2, incluso busca el bloque bzip2, cuyas direcciones también se almacenan en el archivo de índice. Teóricamente, la única parte que debería escalar con el número de archivos es la búsqueda en el índice y que debería escalar con O (log (n)) porque está ordenada por ruta de archivo y nombre.
Huella de memoria
En general, si tiene más de 20k archivos dentro del TAR, la huella de memoria de ratarmount será menor porque el índice se escribe en el disco a medida que se crea y, por lo tanto, tiene una huella de memoria constante de aproximadamente 30 MB en mi sistema.
Una pequeña excepción es el backend del decodificador gzip, que por alguna razón requiere más recuerdos a medida que el gzip se hace más grande. Esta sobrecarga de memoria podría ser el índice requerido para buscar dentro del TAR, pero se necesita más investigación ya que no escribí ese backend.
Por el contrario, archivemount mantiene todo el índice, que es, por ejemplo, 4GB para archivos 2M, completamente en memoria mientras el TAR está montado.
Tiempo de montaje
Mi característica favorita es que Ratarmount pueda montar el TAR sin demora notable en cualquier intento posterior. Esto se debe a que el índice, que asigna nombres de archivo a metadatos y la posición dentro del TAR, se escribe en un archivo de índice creado junto al archivo TAR.
El tiempo requerido para el montaje se comporta un poco raro en archivemount. A partir de aproximadamente 20k archivos, comienza a escalar cuadráticamente en lugar de linealmente con respecto al número de archivos. Esto significa que a partir de aproximadamente 4M de archivos, ratarmount comienza a ser mucho más rápido que archivemount, ¡aunque para archivos TAR más pequeños es hasta 10 veces más lento! Por otra parte, para archivos más pequeños, no importa mucho si se necesita 1s o 0.1s para montar el tar (la primera vez).
Los tiempos de montaje para archivos comprimidos bz2 son los más comparables en todo momento. Esto es muy probable porque está limitado por la velocidad del decodificador bz2. Ratarmount es aproximadamente 2 veces más lento aquí. Espero hacer de Ratarmount el claro ganador al paralelizar el decodificador bz2 en un futuro próximo, lo que incluso para mi sistema de 8 años podría producir una aceleración 4x.
Hora de obtener metadatos
Cuando simplemente enumera todos los archivos finddentro del TAR (¡encontrar también parece llamar a stat para cada archivo !?), ratarmount es 10 veces más lento que archivemount para todos los casos probados. Espero mejorar esto en el futuro. Pero actualmente, parece un problema de diseño debido al uso de Python y SQLite en lugar de un programa en C puro.