En este momento estoy usando ArchiveMountpara montar un archivo de 123,000 kb que contiene más de 3 millones de archivos en su interior. Hasta ahora ha estado montando por más de 5 horas y aún no está terminado.

¿Hay una mejor manera de montar un .tar.gzarchivo? Estoy tratando de montar en una carpeta, y descomprimido toma algunos conciertos. Ni siquiera necesito el modo de escritura, solo lectura es suficiente.

También puedes crear una imagen comprimida de squashfs

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

Para hacer esto, necesitará extraer su archivo tar.gz.

La ventaja también es que la imagen tiene mejor tolerancia a fallas que gz.

El problema aquí es con el formato, el formato TAR (Tape ARchive) está diseñado para acceso secuencial, no para acceso aleatorio. Y gzip es un buen complemento para tar, ya que es un formato de compresión basado en transmisión, tampoco para acceso aleatorio.

Por lo tanto, una herramienta de alto nivel que no interactúa con los bloques comprimidos directamente, tendrá que analizar todo el archivo cada vez que necesite leer algo, primero para obtener la lista de archivos, luego tal vez el caché se invalide y vuelva a leerlo , y luego, por cada archivo que copie, podría leerlo nuevamente. Usted puede hacer una herramienta que recuerda la posición de cada archivo, y qué bloques se necesita descomprimir conseguirlo, pero parece que pocos han molestado con eso.

Si desea que esto vaya más rápido, haga una tar tzf file.tar.gz > filelist, abra esa lista de archivos en vim , gedit o lo que sea, elimine las líneas de archivos que no necesita, guárdelas y luego extráigalas tar xzf file.tar.gz -T filelist -C extracted/.

Para obtener acceso aleatorio a un archivo comprimido, debe usar quizás zip con extensiones posix, rar, o como lo sugiere dru8274, squashfs, o incluso ZFS con compresión activada, o btrfs si btrfs ha conseguido que la compresión funcione al momento de la lectura.

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.

Esto no cubrirá todos los casos de uso, ya que restringe el uso a un editor de texto. Pero, si solo le importa el acceso de lectura, puede que le resulte útil en algunas situaciones. vim, cuando se ejecuta en un tarball le mostrará la jerarquía de contenido del archivo (similar a cómo mostrará una jerarquía de archivos si se ejecuta en un directorio). Al seleccionar uno de los archivos en la lista, se abrirá el archivo seleccionado en un búfer de solo lectura.

Nuevamente, esto no necesariamente ofrece acceso a imágenes u otros medios, pero si todo lo que necesita es ver el contenido o acceder solo a archivos basados ​​en texto, entonces esto debería ser útil.

Nota : esto no funcionará en todos los formatos de archivo.

Mi acercamiento. Si tiene suficiente espacio libre en el disco en una unidad USB externa o en una unidad de disco duro externa / secundaria con suficiente espacio, considere extraer el archivo .tar.gz. Pensando que probablemente no quieres 3 millones de archivos en el disco principal del sistema, ya que eso podría ralentizar las cosas. Recomiendo que el disco externo en este caso tenga un sistema de archivos que maneje una gran cantidad de archivos fácilmente: pensando en ReiserFS, ext4 (con la opción dir_index), XFS, quizás BtrFS. Podría tomar de 1 a 2 horas hacer el extracto, pero puedes ir a almorzar mientras tanto o dejarlo correr durante la noche; cuando regrese, el acceso a los archivos extraídos debe ser efectivo.