Oszacuj skompresowany rozmiar pliku w tar.gz

Mam zestaw .tar.gzplików, które są kopiami zapasowymi duplikatów (pełne kopie zapasowe lub przyrostowe). Chciałbym obliczyć, które katalogi zajmują najwięcej miejsca na kopiach zapasowych. Prawdopodobnie będzie to inna wartość niż obliczanie, które katalogi zajmują najwięcej miejsca w systemie plików na żywo, ponieważ muszę wziąć pod uwagę częstotliwość zmian plików (a tym samym zajmowanie miejsca na przyrostowych kopiach zapasowych) oraz stopień kompresji plików.

Wiem, że podczas gdy wiele innych formatów archiwów przechowuje skompresowane pliki jako różne podmioty w pliku archiwum, .tar.gzpliki nie, i dlatego po kompresji nie jest możliwe uzyskanie dokładnej ilości miejsca zapisanego w archiwum przez pojedynczy plik. Czy są jakieś narzędzia do obliczania przynajmniej niektórych szacunków?

backup tar gzip

— liori
źródło

Odpowiedzi:

Jeśli interesuje Cię określony rozmiar pliku po kompresji, po prostu skompresuj plik za pomocą gzip jeden raz. To powinna być najprostsza metoda.

— John Siu
źródło

Mam prawie terabajt kopii zapasowych i chciałbym obliczyć sumy z każdego skompresowanego pliku… zajęłoby to sporo czasu.

— liori

Zrób pełną kopię zapasową, zrzuć ją na duży pusty dysk. Następnie uruchom ** gzip -r <katalog zrzutu górnego poziomu> **. Możesz podzielić proces na mniejsze części. To wymaga czasu, ale robisz to tylko raz.

— John Siu,

Nie mam takiej wolnej przestrzeni.

— liori

Więc zhakowałem trochę kodu C, aby znaleźć przybliżone wartości. Kod pokazuje, ile bajtów zrobiło zlibodczytanie z archiwum, aby dostać się do każdego kolejnego pliku. Kod jest tutaj: https://github.com/liori/targz-sizes

Wydaje się, że mógłbym wyodrębnić bardziej precyzyjne dane, ale te wartości nie powinny różnić się od rzeczywistych o więcej niż kilka bajtów na plik, a błąd jest uśredniany dla wszystkich plików, więc powinien być wystarczający do celu opisanego w pytanie.

— liori
źródło

tar -xzvOf /pathto/backup.tgz ./inner/pathto/compressed/item | dd > /dev/null- my dd(coreutils 5.97) wypisuje całkowitą liczbę bajtów zapisanych jako3690 bytes (3.7 kB) copied, 0.00244849 seconds, 1.5 MB/s

— jimbobmcgee

@jimbobmcgee: Mierzysz rozmiar rozpakowanego pliku, a nie ile bajtów potrzebuje w skompresowanym archiwum.

— liori

Ach, tęskniłem za tym, czego szukałeś (było to nieco inne niż to , po czym tu przyszedłem!). Chyba wtedy, do zgrubnego oszacowania, odwrotność może być wystarczająco blisko: tar -czvO /pathto/uncompressed/item | dd > /dev/null. Trochę smoły nad głową, ale myślę, że to może być to, czego chcesz. Jeśli nie, zamień tar -czvOna gzip -c.

— jimbobmcgee

... lub (nieco niezręcznie) podróż w obie strony tar -xzvOf /pathto/backup.tgz ./inner/pathto/compressed/item | dd | gzip -c | dd > /dev/null...

— jimbobmcgee

@jimbobmcgee:… co jest niestety nadal błędne, ponieważ (1) podobne pliki umieszczone obok siebie w archiwum tar pomogą sobie nawzajem w kompresji (często w przypadku np. kodu źródłowego), (2) wpisy katalogu i puste pliki również biorą spacja w archiwum - zmienna ilość w zależności od sąsiadów. Dlatego napisałem to narzędzie ;-)

— liori