Napisałem szybszą alternatywną pozycję ratarmount , która „działa dla mnie”, ponieważ problem ten mnie ciągle denerwował.
Możesz użyć tego w następujący sposób:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
Kiedy skończysz, możesz odmontować go jak każdy uchwyt FUSE:
fusermount -u mount-folder
Dlaczego jest szybszy niż archiwizacja?
To zależy od tego, co mierzysz.
Oto punkt odniesienia dla pamięci i wymaganego czasu do pierwszego montażu, a także czasów dostępu dla prostej cat <file-in-tar>komendy i prostej findkomendy.
Utworzono foldery zawierające każdy plik 1k, a liczba folderów jest różna.
Wykres po lewej u dołu pokazuje paski błędów wskazujące minimalny i maksymalny czas pomiaru cat <file>dla 10 losowo wybranych plików.
Czas wyszukiwania pliku
Porównanie zabójców to czas potrzebny cat <file>do ukończenia. Z jakiegoś powodu skaluje się liniowo z rozmiarem pliku TAR (ok. Bajtów na plik x liczba plików) dla archiwizacji, przy jednoczesnym utrzymywaniu stałego czasu w ratarmount. To sprawia, że archivemount w ogóle nie obsługuje wyszukiwania.
Jest to szczególnie zauważalne w przypadku skompresowanych plików TAR.
cat <file>zajmuje ponad dwa razy więcej czasu niż zamontowanie całego pliku .tar.bz2! Na przykład, TAR z 10k pustych (!) Plików wymaga zamontowania z archiwizacją przez 2,9 s, ale w zależności od pliku, do którego uzyskano dostęp, dostęp catzajmuje od 3ms do 5s. Czas potrzebny wydaje się zależeć od pozycji pliku w TAR. Pliki na końcu TAR potrzebują więcej czasu; wskazując, że „seek” jest emulowane i cała zawartość w TAR przed odczytaniem pliku.
Uzyskanie zawartości pliku może zająć ponad dwa razy więcej czasu niż samo zamontowanie całego pliku TAR. Przynajmniej powinien zakończyć się w tym samym czasie co montaż. Jednym z wyjaśnień byłoby to, że plik jest szukany naśladowany więcej niż raz, może nawet trzykrotnie.
Pozyskiwanie pliku Ratarmount z pozoru zajmuje zawsze tyle samo czasu, ponieważ obsługuje prawdziwe wyszukiwanie. W przypadku plików TAR skompresowanych bzip2 szuka nawet bloku bzip2, którego adresy są również przechowywane w pliku indeksu. Teoretycznie jedyną częścią, która powinna być skalowana wraz z liczbą plików, jest wyszukiwanie w indeksie i która powinna być skalowana za pomocą O (log (n)), ponieważ jest ona posortowana według ścieżki pliku i nazwy.
Ślad pamięci
Ogólnie rzecz biorąc, jeśli masz więcej niż 20 000 plików w TAR, to ślad pamięci ratarmount będzie mniejszy, ponieważ indeks jest zapisywany na dysku podczas tworzenia, a zatem ma stały rozmiar pamięci około 30 MB w moim systemie.
Małym wyjątkiem jest backend dekodera gzip, który z jakiegoś powodu wymaga więcej pamięci, gdy gzip staje się większy. Ten narzut pamięci może być indeksem wymaganym do wyszukiwania wewnątrz TAR, ale potrzebne są dalsze badania, ponieważ nie napisałem tego backendu.
W przeciwieństwie do tego, archivemount utrzymuje cały indeks, tj. 4 GB dla plików 2M, całkowicie w pamięci tak długo, jak TAR jest zamontowany.
Czas montażu
Moją ulubioną funkcją jest to, że ratarmount może zamontować TAR bez zauważalnego opóźnienia przy każdej kolejnej próbie. Wynika to z faktu, że indeks, który odwzorowuje nazwy plików na metadane i pozycję wewnątrz TAR, jest zapisywany w pliku indeksu utworzonym obok pliku TAR.
Wymagany czas montażu zachowuje się trochę dziwnie w przypadku archiwizacji. Zaczynając od około 20 000 plików, zaczyna się skalować kwadratowo zamiast liniowo względem liczby plików. Oznacza to, że począwszy od około 4M plików, ratarmount zaczyna być znacznie szybszy niż archiwizowanie, chociaż w przypadku mniejszych plików TAR jest nawet 10 razy wolniejszy! Z drugiej strony, w przypadku mniejszych plików nie ma większego znaczenia, czy zamontowanie tar (po raz pierwszy) zajmuje 1 czy 0,1 s.
Czasy montażu skompresowanych plików BZ2 są zawsze najbardziej porównywalne. Jest to bardzo prawdopodobne, ponieważ jest związane z prędkością dekodera bz2. Ratarmount jest tutaj około 2x wolniejszy. Mam nadzieję, że ratarmount będzie wyraźnym zwycięzcą dzięki równoległemu dekoderowi bz2 w najbliższej przyszłości, co nawet dla mojego 8-letniego systemu może przynieść 4x przyspieszenie.
Czas na metadane
Po prostu wyświetlając listę wszystkich plików findwewnątrz TAR (find wydaje się również wywoływać stat dla każdego pliku !?), ratarmount jest 10 razy wolniejszy niż archiwizacja dla wszystkich testowanych przypadków. Mam nadzieję poprawić to w przyszłości. Ale obecnie wygląda to na problem projektowy z powodu używania Pythona i SQLite zamiast czystego programu C.