На даний момент я використовую ArchiveMountдля установки архіву 123000 кб, який містить понад 3 мільйони файлів всередині. Поки що він монтується протягом 5 годин і досі не закінчений.

Чи є кращий спосіб монтувати .tar.gzфайл? Я намагаюся підключитись до папки, і при нестисненому виконанні потрібно кілька концертів. Мені навіть режим запису не потрібен, достатньо лише читання.

Ви також можете створити стиснене зображення сквош

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

Для цього вам потрібно витягнути архів tar.gz.

Перевагою є також те, що зображення має кращу переносимість несправності, ніж gz.

Проблема тут полягає у форматі, формат TAR (Tape ARchive) призначений для послідовного доступу, а не довільного доступу. І gzip є гарним доповненням до tar, оскільки це формат стиснення, заснований на потоці, також не для випадкового доступу.

Тож інструмент високого рівня, який не взаємодіє зі стиснутими блоками безпосередньо, повинен буде проаналізувати весь файл кожного разу, коли йому потрібно щось прочитати, спочатку отримати вам список файлів, потім, можливо, кеш визнає недійсним, і він прочитає його знову , а потім кожен файл, який ви копіюєте, може повторно прочитати його. Ви можете створити інструмент, який запам'ятовує положення кожного файлу та блоки, які його потрібно розпаковувати, щоб отримати його, але, здається, мало хто з цим переймався.

Якщо ви хочете, щоб це пішло швидше, зробіть tar tzf file.tar.gz > filelist, відкрийте цей список файлів у vim , gedit або будь-якому іншому , видаліть рядки файлів, які вам не потрібні, збережіть і потім витягніть їх tar xzf file.tar.gz -T filelist -C extracted/.

Щоб отримати випадковий доступ до стисненого файлу, вам слід використовувати, можливо, zip з розширенням posix, rar або як запропоновано dru8274, squashfs або навіть ZFS із увімкненою компресією, або btrfs, якщо btrfs отримав компресію для роботи під час читання.

Я написав більш швидкий альтернативний ratarmount , який "працює на мене", тому що ця проблема постійно мене клопотала .

Ви можете використовувати його так:

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

Коли ви закінчите, ви можете його відключити, як будь-яке кріплення FUSE:

fusermount -u mount-folder

Чому це швидше, ніж архів?

Це залежить від того, що ви вимірюєте.

Ось орієнтир слід пам’яті та необхідний час для першого монтажу, а також час доступу для простої cat <file-in-tar>команди та простої findкоманди.

Були створені папки, що містять кожен 1k файл, і кількість папок змінюється.

Нижній лівий графік показує смужки помилок із зазначенням мінімальних та максимальних виміряних разів cat <file>для 10 випадково вибраних файлів.

Файл шукайте час

Порівняння вбивць - це час, який потрібно cat <file>закінчити. З якоїсь причини це масштабується лінійно з розміром файлу TAR (приблизно байтів на файл x кількість файлів) для архівної кількості, будучи постійним часом у ratarmount. Це робить його схожим на те, що архивант навіть не підтримує пошук.

Для стислих файлів TAR це особливо помітно. cat <file>займає більше ніж удвічі більше часу, ніж монтажу всього файлу .tar.bz2! Наприклад, TAR з 10k порожніми (!) Файлами займає 2,9 секунди для монтажу з архівом, але залежно від файлу, до якого доступ, доступ із catзаймає від 3мс до 5с. Час, який потрібно, здається, залежить від положення файлу всередині TAR. Файли в кінці TAR потребують більше часу; що вказує на те, що "шукати" емулюється та весь вміст у TAR перед тим, як файл прочитаний.

Це отримання вмісту файлів може зайняти більше ніж удвічі більше часу, ніж монтаж цілого TAR несподівано. Принаймні, це слід закінчити за стільки ж часу, як і монтаж. Одним із пояснень було б те, що файл не раз переглядається, наприклад, навіть тричі.

Як видається, для отримання файлу Ratarmount завжди потрібна однакова кількість часу, тому що він підтримує справжні пошуки. Для стислих TAR-файлів bzip2 він навіть шукає блок bzip2, адреси якого також зберігаються у файлі індексу. Теоретично, єдина частина, яка має масштабуватись із кількістю файлів, - це пошук в індексі, який повинен масштабуватися з O (log (n)), оскільки він сортується за маршрутом та назвою файлу.

Слід пам'яті

Загалом, якщо у вас є більше 20 кб файлів всередині TAR, то пам'ять пам’яті ratarmount буде меншою, оскільки індекс записується на диск у міру створення, і тому в моїй системі є постійний слід пам’яті приблизно 30 Мб.

Невеликим винятком є ​​декодер gzip-декодера, який з певних причин потребує більше пам’яті, оскільки gzip стає більшим. Цей накладний об'єм пам'яті може бути індексом, необхідним для пошуку всередині TAR, але потрібне подальше дослідження, оскільки я не писав цей запуск.

На відміну від цього, archmount зберігає весь індекс, який, наприклад, 4 Гб для 2M файлів, повністю зберігається в пам'яті настільки, наскільки встановлений TAR.

Час монтажу

Моя улюблена особливість - це рішуча можливість змогти встановити TAR без помітного зволікання при наступній спробі. Це тому, що індекс, який відображає назви файлів для метаданих та позиції всередині TAR, записується у файл індексу, створений поруч із файлом TAR.

Потрібний час для монтажу поводиться якось дивно в архіві. Починаючи з приблизно 20k файлів, він починає масштабуватись квадратично, а не лінійно щодо кількості файлів. Це означає, що починаючи з приблизно 4-мільйонних файлів, ratarmount починає набагато швидше, ніж архівант, хоча для менших файлів TAR це до 10 разів повільніше! Потім знову для менших файлів не має великого значення, чи знадобиться 1s чи 0,1s для монтажу tar (перший раз).

Часи монтажу файлів, що стискаються bz2, є найбільш порівнянними за всі часи. Це дуже ймовірно, оскільки воно пов'язане зі швидкістю декодера bz2. Тут приблизно два рази повільніше. Я сподіваюся зробити перемогу явним переможцем, паралелізуючи декодер bz2 найближчим часом, що навіть для моєї 8-річної системи може призвести до 4-кратного прискорення.

Час отримати метадані

Якщо просто перелічити всі файли, що findзнаходяться всередині TAR (знайти також, схоже, статтю виклику для кожного файлу !?), ratarmount на 10 разів повільніше, ніж архівамент для всіх перевірених випадків. Я сподіваюся на покращення цього в майбутньому. Але в даний час це виглядає як проблема дизайну через використання Python та SQLite замість чистої програми C.

Це не охопить усіх випадків використання, оскільки обмежує використання текстового редактора. Але якщо ви дбаєте лише про доступ до читання, ви можете виявити це корисним у деяких ситуаціях. vim, при запуску на тарбол покаже вам ієрархію вмісту архіву (подібно до того, як він відображатиме ієрархію файлів, якщо запускається в каталозі). Вибравши один із файлів у списку, він відкриє вибраний файл у буфері, доступному лише для читання.

Знову ж таки, це не обов'язково пропонує доступ до зображень або інших носіїв інформації, але якщо все, що вам потрібно, - це переглядати вміст або отримати доступ лише до текстових файлів, то це може бути корисним.

Примітка : це працюватиме не у всіх форматах архіву.

Мій підхід. Якщо у вас є достатньо вільного місця на диску на зовнішньому накопичувачі USB або зовнішньому / вторинному диску жорсткого диска з достатньою кількістю місця, то подумайте лише про вилучення файлу .tar.gz. Думаючи, що ви, мабуть, не хочете 3 мільйони файлів на своєму основному системному диску, оскільки це може уповільнити ситуацію. Я рекомендую, щоб у цьому випадку зовнішній диск мав файлову систему, яка легко обробляє величезну кількість файлів: мислення ReiserFS, ext4 (з опцією dir_index), XFS, можливо, BtrFS. Можливо, це може зайняти 1-2 години, щоб зробити екстракт, але ви можете тим часом піти обідати або пустити його на ніч; коли ви повернетесь, доступ до витягнутих файлів повинен бути корисним.