Saya menulis ratarmount alternatif yang lebih cepat , yang "bekerja untuk saya", karena masalah ini terus mengganggu saya.
Anda bisa menggunakannya seperti ini:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
Setelah selesai, Anda dapat melepasnya seperti pemasangan FUSE:
fusermount -u mount-folder
Mengapa lebih cepat dari jumlah arsip?
Itu tergantung pada apa yang Anda ukur.
Berikut adalah patokan jejak memori dan waktu yang diperlukan untuk pemasangan pertama, serta waktu akses untuk cat <file-in-tar>perintah sederhana dan findperintah sederhana .
Folder yang berisi setiap file 1k dibuat dan jumlah folder bervariasi.
Plot kiri bawah menunjukkan bilah kesalahan yang menunjukkan waktu pengukuran minimum dan maksimum cat <file>untuk 10 file yang dipilih secara acak.
Waktu pencarian file
Perbandingan pembunuh adalah waktu yang dibutuhkan untuk cat <file>menyelesaikannya. Untuk beberapa alasan, ini menskala secara linear dengan ukuran file TAR (kira-kira byte per file x jumlah file) untuk archivemount sementara menjadi waktu yang konstan dalam ratarmount. Ini membuatnya tampak seperti archivemount bahkan tidak mendukung pencarian sama sekali.
Untuk file TAR terkompresi, ini terutama terlihat.
cat <file>membutuhkan waktu lebih dari dua kali selama pemasangan seluruh file .tar.bz2! Sebagai contoh, TAR dengan 10k file kosong (!) Membutuhkan 2.9s untuk di-mount dengan archivemount tetapi tergantung pada file yang diakses, akses dengan catmembutuhkan antara 3ms dan 5s. Waktu yang dibutuhkan tampaknya tergantung pada posisi file di dalam TAR. File di akhir TAR membutuhkan waktu lebih lama untuk dicari; menunjukkan bahwa "mencari" ditiru dan semua konten dalam TAR sebelum file dibaca.
Bahwa mendapatkan konten file dapat memakan waktu lebih dari dua kali lipat dari pemasangan seluruh TAR tidak terduga dalam dirinya sendiri. Paling tidak, itu harus selesai dalam jumlah waktu yang sama dengan pemasangan. Salah satu penjelasannya adalah bahwa file sedang ditiru secara dicari untuk lebih dari sekali, bahkan mungkin tiga kali.
Ratarmount tampaknya selalu membutuhkan jumlah waktu yang sama untuk mendapatkan file karena mendukung pencarian yang sebenarnya. Untuk TAR terkompresi bzip2, bahkan mencari blok bzip2, yang alamatnya juga disimpan dalam file indeks. Secara teoritis, satu-satunya bagian yang harus skala dengan jumlah file adalah pencarian dalam indeks dan yang harus skala dengan O (log (n)) karena diurutkan berdasarkan jalur dan nama file.
Jejak memori
Secara umum, jika Anda memiliki lebih dari 20k file di dalam TAR, maka jejak memori ratarmount akan lebih kecil karena indeks ditulis ke disk saat dibuat dan karenanya memiliki jejak memori konstan sekitar 30MB pada sistem saya.
Pengecualian kecil adalah backend gzip decoder, yang karena beberapa alasan memerlukan lebih banyak memori karena gzip semakin besar. Memori overhead ini mungkin merupakan indeks yang diperlukan untuk mencari di dalam TAR tetapi penyelidikan lebih lanjut diperlukan karena saya tidak menulis backend itu.
Sebaliknya, archivemount menyimpan seluruh indeks, yaitu, misalnya, 4GB untuk file 2M, sepenuhnya dalam memori selama TAR dipasang.
Waktu pemasangan
Fitur favorit saya adalah ratarmount untuk dapat memasang TAR tanpa terasa menunda pada percobaan berikutnya. Ini karena indeks, yang memetakan nama file ke metadata dan posisi di dalam TAR, ditulis ke file indeks yang dibuat di sebelah file TAR.
Waktu yang diperlukan untuk pemasangan berperilaku agak aneh di archivemount. Mulai dari kira-kira 20k file mulai skala secara kuadratik bukan linier sehubungan dengan jumlah file. Ini berarti bahwa mulai dari kira-kira file 4M, ratarmount mulai jauh lebih cepat daripada archivemount walaupun untuk file TAR yang lebih kecil itu hingga 10 kali lebih lambat! Kemudian lagi, untuk file yang lebih kecil, tidak masalah apakah dibutuhkan 1s atau 0,1s untuk me-mount tar (pertama kali).
Waktu pemasangan untuk file terkompresi bz2 adalah yang paling sebanding setiap saat. Ini sangat mungkin karena diikat oleh kecepatan decoder bz2. Ratarmount kira-kira 2x lebih lambat di sini. Saya berharap menjadikan ratarmount pemenang yang jelas dengan memparalelkan bz2 decoder dalam waktu dekat, yang bahkan untuk sistem saya yang berusia 8 tahun dapat menghasilkan speedup 4x.
Saatnya mendapatkan metadata
Ketika hanya mendaftarkan semua file dengan finddi dalam TAR (cari juga tampaknya memanggil stat untuk setiap file !?), ratarmount adalah 10x lebih lambat dari archivemount untuk semua kasus yang diuji. Saya berharap untuk memperbaiki ini di masa depan. Tapi saat ini, sepertinya masalah desain karena menggunakan Python dan SQLite daripada program C murni.