On 11/28/2012 09:50 AM, Michał Górny wrote: > On Wed, 28 Nov 2012 10:05:55 -0500 > Richard Yao <r...@gentoo.org> wrote: > >> On 11/28/2012 09:17 AM, Maxim Kammerer wrote: >>> On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao <r...@gentoo.org> wrote: >>>> We could slightly simplify the handbook installation procedure if we >>>> told people to use emerge-webrsync to fetch the initial snapshot. >>> >>> Using emerge-webrsync also makes the installation process more robust, >>> since it only requires HTTP access (whereas many firewalls restrict >>> RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think >>> that it should be the primary recommended portage tree synchronization >>> method. >>> >> >> The only downside of which I am aware is increased network traffic. >> However, we could redesign emerge-webrsync to take advantage of GNU >> Tar's incremental archive functionality. >> >> That would permit us to mirror compressed diffs in addition to regular >> portage snapshots. Doing that well could reduce bandwidth requirements. > > There's emerge-delta-webrsync but it's mostly hand-work to reconstruct > the webrsync tarball. Therefore, it is very slow and not worth > the effort when syncing often.
At least because I maintain emerge-delta-webrsync, I use it regularly as my sync method. Latest versions of emerge-delta-webrsync use a temp directory inside $PORTAGE_TMPDIR/portage, on which I have a tmpfs filesystem mounted. With tmpfs, performance does not seem so bad (using a sandy bridge core i5 here). > However, I'm not aware of gnu tar's incremental archive. If it's much > faster than the above, then it should probably replace > emerge-delta-webrsync. If it has benefits over the current diffball approach used by emerge-delta-webrsync, then it seems like a good idea. It would be nice to integrate it directly into emerge-webrsync, and eventually deprecate emerge-delta-webrsync. -- Thanks, Zac
