On Thu, 15 Dec 2005, Ben Escoto wrote: > >>>>> "Hans F. Nordhaug" <[EMAIL PROTECTED]> > >>>>> wrote the following on Tue, 13 Dec 2005 09:47:15 +0100 > > > > However, other (easier) approaches come to mind: > > 1) Never, ever gzip an empty file. All my error_log files have size > > 108 in stead of 0 zero because they are compressed. > > 2) Don't write any logs or session data if there are no changes. > > (Make it an option or the default.) This would help a lot! > > Yes, I think the error_log file could be skipped if there are no > errors. Anyone see any drawbacks to this?
Which filesystems allocate disk space for an empty file? AFAIK, ext2 only uses an entry in the 'directory', but no blocks for contents. So, by just not gzipping an empty file, it will probably take less space already. I currently use the error_log file as a means to check the result of the rdiff-backup run. Attaching the contents of `ls error_log*|tail -n1` to a cron email is quite easy, but would give strange results when no error_log file was created in the last run. While my crude error_log selection line could be adjusted to use e.g. the timestamp from the current_mirror file, I really prefer to have all log and session files, even if they're empty. If deleting (or not creating) file_statistics files is possible, and mirror_metadata files are managed incrementally, I doubt there will be much overhead in disk usage. And a few megabytes is a small price to pay for long-term "incremental restores". A switch for not writing session_statistics files might be useful, but adding an 'rm rdiff-backup-data/session_statistics*' in the script calling rdiff-backup shouldn't be too hard either. -- Maarten _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
