Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tools: add zsync #1905

Closed
wants to merge 2 commits into from
Closed

tools: add zsync #1905

wants to merge 2 commits into from

Conversation

aparcar
Copy link
Member

@aparcar aparcar commented Mar 7, 2019

create tar.xz files for ImageBuilder and SDK. This saves bandwidth when daily updating local snapshots.

Signed-off-by: Paul Spooren <mail@aparcar.org>
Add config option to create zsync index file for created ImageBuilder
and SDKs.

Signed-off-by: Paul Spooren <mail@aparcar.org>
@aparcar aparcar changed the title Zsync tools: add zsync Mar 7, 2019
@diizzyy
Copy link
Contributor

diizzyy commented Mar 7, 2019

Wouldn't it make more sense to have bsdiff and/or https://github.com/thoughtpolice/minibsdiff ?
I know Debian looked into this at some point and found it to be much more efficient than zsync? I'll have a look if I can find that post again later

@aparcar
Copy link
Member Author

aparcar commented Mar 7, 2019

I think that's a different approach. Using (mini)bsdiff would require to keep patches of all previous snapshot builds and also keep versions of them, so downloading clients would know where to start. However with zsync it compares the local file with an index (.zsync) provided by the server.

@diizzyy
Copy link
Contributor

diizzyy commented Mar 8, 2019

Perhaps do a weekly schedule or something, I'm not sold on using something like zsync. Something like librevault (p2p) would make more sense but that project seems dead...

@chunkeey chunkeey added the build/scripts/tools pull request/issues for build, scripts and tools related changes label Mar 8, 2019
@dangowrt
Copy link
Member

@aparcar
Copy link
Member Author

aparcar commented Mar 12, 2019

I gave it a try and it resulted in bandwidth saving of ~25%. This is somewhat poor but considering that zsync doesn't work with tar.xz...

The resulting .zsync file took some ~165KB for the ar71xx/generic ImageBuilder, I think that size is feasible to give it a try.

In some future someone (:tm:) could add tar.xz support.

@diizzyy
Copy link
Contributor

diizzyy commented Mar 12, 2019

I'd also be hesitant use something that's more or less dead upstream.
portsnap might be worth looking into but it's a bit FreeBSD-centric and forking it would essentially mean "no support".

https://svnweb.freebsd.org/base/head/usr.sbin/portsnap/portsnap/portsnap.sh?revision=326276&view=markup
https://en.wikipedia.org/wiki/Portsnap

First step would be to evaluate how well bspatch (bsdiff) handles xz compressed archives.

PKG_RELEASE:=1

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://codeload.github.com/ahmedammar/zsync/tar.gz/$(PKG_VERSION)?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer using a git+https:// download with a hash over an external service.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I don't understand what you mean, could you please point me to an example where it is done this way?

Copy link
Member

@adschm adschm Oct 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it means: You should not use codeload.github.com but some other source.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

local tarball basically.

There's no good solution. codeload changes the hashes from time to time (I've only seen it when using submodules) and local tarballs also change hashes in surprising ways. Many of the tarballs currently on the OpenWrt mirrors have wrong hashes. It causes no issues as it falls back to cloning the git repo (not a shallow clone oddly enough).

The latter is smaller as it uses .xz as an archive, usually.

@adschm
Copy link
Member

adschm commented Oct 31, 2019

I'd also be hesitant use something that's more or less dead upstream.

@aparcar Can you respond on this?

@aparcar
Copy link
Member Author

aparcar commented Oct 31, 2019

Sure let's close this, we got a cdn now anyway and the the space saving is not that great...

@aparcar aparcar closed this Oct 31, 2019
@aparcar aparcar deleted the zsync branch October 31, 2019 21:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build/scripts/tools pull request/issues for build, scripts and tools related changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants