I'm curious as to what exactly is doing to compress metadata files. I recently had occasion to unzip a couple of them (I wanted to remove a file - yes, I know it's dodgy, but I had backed up a 30+ GB file I didn't want to keep) and when I compressed them again, some were larger than the originals. Not by much of course, and in the context of an rdiff backup the disk space used isn't the issue at all - I'm just curious as to what rdiff-backup is doing that the gzip standalone program isn't:
root@serverm:/tmp/mirror_metadata# ls -l total 9828 -rw-r--r-- 1 root root 9554194 Nov 1 12:01 mirror_metadata.2013-10-23T01:54:06+02:00.snapshot.gz -rw------- 1 root root 486893 Nov 1 12:01 mirror_metadata.2013-10-31T03:06:42+01:00.diff.gz root@serverm:/tmp/mirror_metadata# gunzip * root@serverm:/tmp/mirror_metadata# ls -l total 70800 -rw-r--r-- 1 root root 69103098 Nov 1 12:01 mirror_metadata.2013-10-23T01:54:06+02:00.snapshot -rw------- 1 root root 3316456 Nov 1 12:01 mirror_metadata.2013-10-31T03:06:42+01:00.diff root@serverm:/tmp/mirror_metadata# gzip --best * root@serverm:/tmp/mirror_metadata# ls -l total 9832 -rw-r--r-- 1 root root 9554194 Nov 1 12:01 mirror_metadata.2013-10-23T01:54:06+02:00.snapshot.gz -rw------- 1 root root 488606 Nov 1 12:01 mirror_metadata.2013-10-31T03:06:42+01:00.diff.gz The snapshot file ended up the exact same size, but the diff file is a little (about 0.35% ;-) ) smaller. I had a read of http://www.gzip.org/zlib/rfc-gzip.html and if anything the original file should have been marginally bigger, as it, in contravention of the file format specification, stores the full path of the compressed file in the filename component of the header, thus needing a few extra bytes. So, any ideas what might be happening? Kindest regards, Niall O Broin _______________________________________________ rdiff-backup-users mailing list at [email protected] https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
