From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.3/8.13.3) with ESMTP id j2MNwPuM017222 for ; Tue, 22 Mar 2005 23:58:25 GMT Received: from hulk.vianw.pt ([195.22.31.43]) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DDtGS-0005Fd-HY for gentoo-dev@robin.gentoo.org; Tue, 22 Mar 2005 23:58:24 +0000 Received: from wizy.org ([80.172.5.187]) by hulk.vianw.pt (8.13.3/8.13.3) with ESMTP id j2MNwJGa016081 for ; Tue, 22 Mar 2005 23:58:22 GMT Received: from localhost (localhost [127.0.0.1]) by wizy.org (Postfix) with ESMTP id 799F81A8EE48E for ; Tue, 22 Mar 2005 23:58:19 +0000 (WET) From: Ricardo Correia To: gentoo-dev@robin.gentoo.org Subject: Re: [gentoo-dev] Proposal for an alternative portage tree sync method User-Agent: KMail/1.7.2 References: <200503220715.02669.gentoo-dev@wizy.org> <1111499711.7251.16.camel@localhost> In-Reply-To: <1111499711.7251.16.camel@localhost> Precedence: bulk List-Post: , , List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-To: gentoo-dev@gentoo.org MIME-Version: 1.0 Content-Disposition: inline X-UID: 944 X-Length: 1976 Date: Tue, 22 Mar 2005 23:58:19 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503222358.19166.gentoo-dev@wizy.org> X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on hulk.vianw.pt X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on hulk.vianw.pt X-Virus-Status: Clean X-Archives-Salt: 6392df35-0dbc-4d61-a054-11c6be925df7 X-Archives-Hash: f4daf9b816ba2ab945676ef9f4858953 On Tuesday 22 March 2005 13:55, Patrick Lauer wrote: > > A few problems: > - that .iso and the .zsync metadata need to be generated. More load on > master server > - isos don't allow easy access, e.g. writing a few bytes for a tricial > bugfix > - mkisofs might shuffle the data so that transferring one large file > might cause more traffic than rsync does now > > I don't see the advantages over tar + binary diffs. > You make valid points, but notice: - The .zsync metadata doesn't have to be generated on the master server. Anyone can do it right now. - ISO's would have to be regenerated periodically. This could vary from every 30 minutes to only once per day, we'd have to see how it works. Personally I think every 30 minutes would be viable, but it's not really necessary. Once per day would be enough and better than emerge-webrsync.. The advantage over tar + binary diffs: - Client doesn't have to remove entire portage tree and extract the tar file every sync. - I think xdelta might be possible, but bsdiff would be impossible due to the memory requirements for a tar this large. I don't really know how xdelta performs CPU-wise and memory-wise.. - It's simpler (only 2 files on the server and very few commands necessary) :-) -- gentoo-dev@gentoo.org mailing list