> > Well, a block size of 2048 makes the .zsync ~1% of the size of the > > original file - and it is relative size which is interesting. But > > Well, that is obviously wrong, as it's also absolute size that is > interesting for me, because I can only use it if the .zsync files get > smaller.
I disagree. There are 3 points of view: - if I'm the admin of a server offering downloads, what I care about is the increase in disk usage if I offer zsyncs as well - I don't care about a 1Meg zsync file if it is for a 1Gig ISO image. - if I'm a downloader, I don't care about the size of the zsync file, I care about total download size. The empirical results section of my technical paper shows that block sizes of 1024 or 2048 bytes, with zsync files which are 1-2% the size of the main file, were optimal for zsync-0.1.x. - finally, if I'm running moria.org.uk, offering .zsync files for other people's big ISO files, then I care only about absolute size, because I don't pay for the bandwidth or storage for the actual data file. But this isn't the main use case. This said, zsync-0.2.x has massively reduced the size of the .zsync file, so .zsyncs of <1% are now normal for uncompressed files, and the program is very effective with 0.5-1% for compressed files. zsync now transmits no more metadata than rsync in most cases. But I'm standing by the idea that it's relative size that matters :-) > 8192 is not a valid value, according to the referenced zsyncmake(1) > manpage, Good point about the man page; the documentation needs updating. I will make explicit the block sizes considered sane for normal and for compressed files for the next release. -- Colin Phipps <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
