Version 1.1.1 released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Version 1.1.1 released

Ben Escoto
A few new features this version.  Next on my list is cleaning up some
rdiff-backup stdout/stderr (especially stack traces), which a few
people have requested, and making sure Mac OS X works (I think we're
getting close now).


>From the CHANGELOG:

New in v1.1.1 (2005/11/05)
--------------------------

rdiff-backup now writes SHA1 sums into its mirror_metadata file for
all regular files, and checks them when restoring.

The above greatly increases the size of the mirror_metadata files, so
diff them for space efficiency, as suggested by Dean Gaudet.

Added two new comparison modes: full file (using the --compare-full or
--compare-full-at-time) or by hash (--compare-hash and
--compare-hash-at-time).

Applied Alec Berryman's patch to update the no-compression regexp.

Alec Berryman's fs_abilities patch is supposed to help with AFS.

Fixed filename-too-long crash when quoting.

Patched carbonfile support, re-enabled it by default.


--
Ben Escoto

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version 1.1.1 released

Dave Kempe
Ben Escoto wrote:
> rdiff-backup now writes SHA1 sums into its mirror_metadata file for
> all regular files, and checks them when restoring.

I haven't had a chance to test it yet, but I bet that pounds CPU bound
boxes. I have quite a few of these and would love a way to turn this
feature off - is that going to happen? Happy to have it default - most
aren't CPU bound.

dave


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Version 1.1.1 released

Ben Escoto
>>>>> David Kempe <[hidden email]>
>>>>> wrote the following on Sun, 06 Nov 2005 20:11:17 +1100
>
> I haven't had a chance to test it yet, but I bet that pounds CPU
> bound boxes. I have quite a few of these and would love a way to
> turn this feature off - is that going to happen? Happy to have it
> default - most aren't CPU bound.

It would be possible to add the option, but I'd like to see some
numbers before deciding if the extra complexity were worth it.
rdiff-backup consumes a lot of CPU when dealing with small files, or
searching through files that haven't changed, and I would guess that
this new feature uses up the most CPU in the opposite circumstance,
when rdiff-backup is processing large files with lots of data to hash,
and so usually isn't CPU bound.

For testing, I think you may just be able to comment out the

                self.sha1.update(buf)

line in hash.py.  No file data will be processed by the hash
algorithm, so all your files will show up with the same hash of a
0-byte file.


--
Ben Escoto

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version 1.1.1 released

halfgaar
In reply to this post by Ben Escoto
Firstly, the GPG signature on your mail failed. Is the mail authentic?

Ben Escoto wrote:

>>From the CHANGELOG:
>
>New in v1.1.1 (2005/11/05)
>--------------------------
>
>rdiff-backup now writes SHA1 sums into its mirror_metadata file for
>all regular files, and checks them when restoring.
>
>The above greatly increases the size of the mirror_metadata files, so
>diff them for space efficiency, as suggested by Dean Gaudet.
>  
>
Does the user have control over diffing the metafiles, with a new
feature? I thought you had decided against that, because it would make
the archive more prone to errors.


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version 1.1.1 released

Ben Escoto
>>>>> Wiebe Cazemier <[hidden email]>
>>>>> wrote the following on Sun, 06 Nov 2005 18:45:08 +0100

> Firstly, the GPG signature on your mail failed. Is the mail
> authentic?

Yes, although my mailer also thinks the signature is bad.  That's
weird, I'm not sure what happened.

> Does the user have control over diffing the metafiles, with a new
> feature? I thought you had decided against that, because it would
> make the archive more prone to errors.

No, in this version it's a mandatory feature.  As for errors, I took a
compromise position.  Firstly, rdiff-backup won't extend the string of
diffs longer than 9.  So if you do a lot of backups your
mirror_metadatas will look like:

<snapshot>
<diff 1>
...
<diff 9>
<snapshot>
<diff 1>
...
<diff 9>
<snapshot>
...etc

avoiding the need for a string of diffs 100+ files long to be intact.
Since the diffs will probably be much smaller than the snapshot
(especially with the uncompressable sha1 info added), the snapshot +
diffs probably aren't much bigger than the snapshot.  If the chance of
corruption is roughly proportional to the total size, then there isn't
much increase in total corruption risk.

Also diffs aren't written when the files are being incremented.
rdiff-backup will write the snapshot first, sync it, then as a final
step reread the snapshot, write a diff, and delete the snapshot.  If
rdiff-backup gets interrupted, the regress step knows that if there is
both a diff and a snapshot, then the snapshot must be fully written
but the diff may have been interrupted.


--
Ben Escoto

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment