Al momento sto usando ArchiveMountper montare un archivio da 123.000 kb che contiene più di 3 milioni di file all'interno. Finora è stato montato per oltre 5 ore e non è ancora finito.

C'è un modo migliore per montare un .tar.gzfile? Sto cercando di montare su una cartella e non compresso ci vogliono alcuni concerti. Non ho nemmeno bisogno della modalità di scrittura, è sufficiente la sola lettura.

Puoi anche creare un'immagine compressa di squashfs

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

Per fare ciò dovrai estrarre il tuo archivio tar.gz.

Il vantaggio è anche che l'immagine ha una migliore tolleranza agli errori rispetto a gz.

Il problema qui è con il formato, il formato TAR (Tape ARchive) è progettato per l'accesso sequenziale, non casuale. E gzip è un buon complemento di tar, dal momento che è un formato di compressione basato su stream, anche non per l'accesso casuale.

Quindi uno strumento di alto livello che non interagisce direttamente con i blocchi compressi, dovrà analizzare l'intero file ogni volta che deve leggere qualcosa, prima per ottenere l'elenco dei file, quindi forse la cache si annulla e la legge di nuovo e quindi per ogni file copiato potrebbe essere letto nuovamente. È possibile fare uno strumento che ricorda la posizione di ogni file, e quali blocchi di cui ha bisogno per decomprimere per farlo, ma sembra che pochi hanno disturbato con questo.

Se vuoi che questo vada più veloce, fai un tar tzf file.tar.gz > filelist, apri quell'elenco di file in vim , gedit o altro, rimuovi le righe di file che non ti servono, salvale e poi estraile tar xzf file.tar.gz -T filelist -C extracted/.

Per ottenere l'accesso casuale a un file compresso, dovresti usare forse zip con estensioni posix, rar o come suggerito dru8274, squashfs o persino ZFS con la compressione attivata o btrfs se btrfs ha ottenuto la compressione per funzionare al momento della lettura.

Ho scritto un ratarmount alternativo più veloce , che "funziona per me", perché questo problema continuava a infastidirmi.

Puoi usarlo in questo modo:

pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level

Al termine, puoi smontarlo come qualsiasi attacco FUSE:

fusermount -u mount-folder

Perché è più veloce di archivemount?

Dipende da cosa misuri.

Ecco un benchmark di footprint di memoria e tempo richiesto per il primo montaggio, nonché tempi di accesso per un cat <file-in-tar>comando semplice e un findcomando semplice .

Sono state create cartelle contenenti ogni file 1k e il numero di cartelle è variato.

Il grafico in basso a sinistra mostra barre di errore che indicano i tempi minimi e massimi misurati cat <file>per 10 file scelti casualmente.

Tempo di ricerca file

Il confronto killer è il tempo necessario per cat <file>terminare. Per qualche motivo, questo si ridimensiona linearmente con la dimensione del file TAR (circa byte per file x numero di file) per l'archiviazione, pur essendo di tempo costante in ratarmount. Questo fa sembrare che archivemount non supporti nemmeno la ricerca.

Per i file TAR compressi, questo è particolarmente evidente. cat <file>richiede più del doppio del montaggio dell'intero file .tar.bz2! Ad esempio, il TAR con 10k di file vuoti (!) Richiede 2,9 secondi per il montaggio con archivemount ma, a seconda del file a cui si accede, l'accesso con catrichiede tra 3ms e 5s. Il tempo impiegato sembra dipendere dalla posizione del file all'interno del TAR. I file alla fine del TAR richiedono più tempo per essere cercati; indicando che la "ricerca" viene emulata e tutti i contenuti nel TAR prima della lettura del file.

Che ottenere il contenuto del file può richiedere più del doppio del tempo rispetto al montaggio dell'intero TAR è inaspettato su se stesso. Almeno, dovrebbe finire nello stesso lasso di tempo del montaggio. Una spiegazione sarebbe che il file viene cercato in modo emulato più di una volta, forse anche tre volte.

Apparentemente Ratarmount impiega sempre la stessa quantità di tempo per ottenere un file perché supporta la vera ricerca. Per i TAR compressi bzip2, cerca anche il blocco bzip2, i cui indirizzi sono anche memorizzati nel file indice. Teoricamente, l'unica parte che dovrebbe ridimensionare con il numero di file è la ricerca nell'indice e che dovrebbe ridimensionare con O (log (n)) perché è ordinato per percorso e nome del file.

Impronta di memoria

In generale, se hai più di 20k file all'interno del TAR, allora l'impronta di memoria di ratarmount sarà più piccola perché l'indice viene scritto sul disco mentre viene creato e quindi ha un footprint di memoria costante di circa 30 MB sul mio sistema.

Una piccola eccezione è il backend del decoder gzip, che per qualche motivo richiede più memorie man mano che il gzip si ingrandisce. Questo sovraccarico di memoria potrebbe essere l'indice richiesto per la ricerca all'interno del TAR, ma sono necessarie ulteriori indagini poiché non ho scritto quel backend.

Al contrario, archivemount mantiene l'intero indice, che è, ad esempio, 4 GB per file 2M, completamente in memoria fino a quando il TAR è montato.

Tempo di montaggio

La mia funzione preferita è ratarmount, essendo in grado di montare il TAR senza ritardi evidenti in qualsiasi tentativo successivo. Questo perché l'indice, che associa i nomi dei file ai metadati e alla posizione all'interno del TAR, viene scritto in un file indice creato accanto al file TAR.

Il tempo richiesto per il montaggio si comporta in modo un po 'strano in archivio. A partire da circa 20k file inizia a ridimensionare quadraticamente anziché linearmente rispetto al numero di file. Ciò significa che a partire da circa 4 milioni di file, ratarmount inizia a essere molto più veloce di archivemount anche se per file TAR più piccoli è fino a 10 volte più lento! Inoltre, per file più piccoli, non importa molto se sono necessari 1 o 0,1 secondi per montare il tar (la prima volta).

I tempi di montaggio per i file compressi bz2 sono i più comparabili in ogni momento. Ciò è molto probabile perché è legato dalla velocità del decodificatore bz2. Ratarmount è circa 2 volte più lento qui. Spero di rendere ratarmount il chiaro vincitore parallelizzando il decoder bz2 nel prossimo futuro, che anche per il mio sistema di 8 anni potrebbe portare a un 4x speedup.

È ora di ottenere metadati

Quando si elencano semplicemente tutti i file con findall'interno del TAR (anche find sembra chiamare stat per ogni file !?), ratarmount è 10 volte più lento di archivemount per tutti i casi testati. Spero di migliorare questo aspetto in futuro. Ma attualmente, sembra un problema di progettazione a causa dell'utilizzo di Python e SQLite invece di un programma C puro.

Questo non coprirà tutti i casi d'uso in quanto limita l'uso a un editor di testo. Ma, se ti interessa solo l'accesso in lettura, potresti trovare utile in alcune situazioni. vim, quando eseguito su un tarball ti mostrerà la gerarchia dei contenuti dell'archivio (simile a come mostrerà una gerarchia di file se eseguita su una directory). Selezionando uno dei file nell'elenco, si aprirà il file selezionato in un buffer di sola lettura.

Ancora una volta, ciò non offre necessariamente l'accesso a immagini o altri media, ma se tutto ciò che serve è vedere i contenuti o accedere solo ai file basati su testo, questo dovrebbe essere utile.

Nota : questo non funzionerà su tutti i formati di archivio.

Il mio approccio Se si dispone di spazio libero su disco sufficiente su un'unità USB esterna o su un'unità HDD esterna / secondaria con spazio sufficiente, prendere in considerazione solo l'estrazione del file .tar.gz. Pensando che probabilmente non vuoi 3 milioni di file sul tuo disco di sistema principale, in quanto ciò potrebbe rallentare le cose. Raccomanderei che il disco esterno in questo caso abbia un filesystem che gestisca facilmente un numero enorme di file: pensando a ReiserFS, ext4 (con opzione dir_index), XFS, forse BtrFS. Potrebbero essere necessarie 1-2 ore per fare l'estratto, ma potresti semplicemente andare a pranzare nel frattempo o lasciarlo correre durante la notte; quando torni, l'accesso ai file estratti dovrebbe essere performante.