On Sun, Jan 30, 2005 at 09:18:12AM -0800, Debian Bug Tracking System <[EMAIL PROTECTED]> wrote: > #292040: zsync: allow larger blocksizes, or dynamic blocksizes like rsync, > which was filed against the zsync package. > > Their explanation is attached below. If this explanation is
Sorry, didn't get the explanation, but I copied it out of the bts, which is probably the explanation that was referenced by this part: > see above > > --=20 > Robert Lemmen http://www.semistable.com=20 I don't think the wishlist request is fulfilled by the current package, because of: > 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. It's not a bug, just a wishlist that might or might not get implemented. > It does - zsyncmake(1) documents the -b option. One of my test cases is > > an ISO file with a .zsync with blocksize 8192. If there is a limitation > 8192 is not a valid value, according to the referenced zsyncmake(1) manpage, which is probably a limitation you are not aware with: -b blocksize Specify the blocksize to the underlying rsync algorithm. A smaller blocksize may be more efficient for files where there are likely to be lots of small, scattered changes between downloads; a larger blocksize may be more efficient for files with larger blocks of contiguous new or old data. This blocksize must be a power of two - donât use anything other than 512, 1024 or 2048 unless you know what you are doing (although in that case you probably shouldnât even think of changing it anyway :-). i.e. other values 512, 1024 and 2048 are explicitly "don't use". If this is wrong then this should be documented. > that I am not aware of, please give an example. The only limitation I do > well, "power-of-two" is (as you state) another limitation unique to zsync over rsync. I, too, think that it's not the most worthy optimization, but it doesn't hurt me at all, so I don't "wish" for it to change :) > know of is that very large block sizes don't work for compressed files. > Well, what is "very large"? Obviously, zsync doesn't use the same algorithm as rsync (probably a very similar one, though), so it would be nice to know what values people can use for the options, if other values than 512, 1024 and 2048 are in fact allowed and work, they should be documented. I got the strong impression by the wording in the manpage that bad things would happen if one used larger blocksizes, and indeed they don't seem to work for some unknown values, so my impression at least is not completely unwarranted. It would be very nice if larger vlaues would work, and if they do, that the wording in the manpage might mention them as legal values. Please remember, this is just a wishlist, not a demand and certainly not a bug. -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
