Michał Górny posted on Fri, 17 Jan 2014 17:27:30 +0100 as excerpted: > Now some numbers. I did some tests 'converting' late gx86 daily tarballs > to squashfs. I've used squashfs 4.2 with LZO compression since it's > quite good and very fast. > > 96M portage-20140108.sqfs [...] > 97M portage-20140114.sqfs > 97M portage-20140115.sqfs > > For deltas [...] > > 4,9M portage-20140108.sqfs-portage-20140109.sqfs.vcdiff.djw > 6,3M portage-20140109.sqfs-portage-20140110.sqfs.vcdiff.djw [...] > 8,5M portage-20140114.sqfs-portage-20140115.sqfs.vcdiff.djw > > As you can see, the deltas are quite large compared to the actual > changes. However, we could have expected that since we're diffing a > compressed filesystem. What's important, however, is that applying it > takes ~2.5 second on my 2 GHz Athlon64.
And... eyeballing a 6 MiB average, diffs are ~1/16 the full squashfs size, perhaps a bit larger. So people updating once a week or even about every 10 days would see a bandwidth savings, provided the sync script was intelligent enough to apply updates serially. The breakover point would be roughly an update every two weeks, or twice a month, at which point just downloading a new full squashfs would be easier, at about the same bandwidth. > What do you think? How does this, particularly the metadata cache, interact with overlays? That's /my/ big question. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
