Data loss (corruption with rsync)
Matt McCutchen
matt at mattmccutchen.net
Fri Dec 4 15:37:08 MST 2009
On Sat, 2009-12-05 at 00:19 +0200, kordex - wrote:
> Discussion in enlightened irc channel (OFTC/#ck) gave possible clue
> for solving this, although it's just a quess:
>
> 0006 @ con || KordeX >4GB file?
> 0007 + KordeX || not all of those are
> 0007 + KordeX || i mean most of them are <100MB
> 0007 @ con | yes but that's the reason it failed
> 0008 @ con | rsync uses the rzip algorithm which was 32bit limited as I
> discovered whenI was updating lrzip
> 0012 + KordeX || con > it uses rzip even when not using any --compress?
> 0012 + KordeX || or does it use it when using append-verify or fuzzy options?
> 0012 @ con | I'm not sure but it uses the rzip for the diff function I
> think
> 0013 + KordeX || oh that's the reason i was affected
> 0013 + KordeX || i think i should re: re: my email with that update
> 0013 @ con | actually I'm guessing
> 0014 + KordeX || well i add this anyways, give one clue to them
> 0014 @ con | dont quote me on that, but I had all sorts of troubles
> dealing with > 2^32 sized files with the rzip code
> 0014 @ con | and I had to rewrite most of the rzip algorithm to be 64bit
> smart
> 0014 @ con | which unfortunately also slowed it down quite a lot
> 0015 @ con | unless you were working on >4GB files that is, where it sped
> it up
Rsync and rzip do not share code, though the algorithms may be similar.
I don't believe a 2^32-byte limit exists in the current version of
rsync.
--
Matt
More information about the rsync
mailing list