From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id DA47C1F404; Fri, 9 Feb 2018 20:51:40 +0000 (UTC) Date: Fri, 9 Feb 2018 20:51:40 +0000 From: Eric Wong To: meta@public-inbox.org Subject: [v2] one file to rule them all? Message-ID: <20180209205140.GA11047@dcvr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline Content-Transfer-Encoding: 8bit List-Id: --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Since 95acd5901491e4f333f5d2bbeed6fb5e6b53e07c ("searchmsg: add git object ID to doc_data") the need for having file stored in trees is reduced since Xapian stores the git object_id and asks git to retrieve it without doing tree lookups. So, as long as git knows an object exists, it should be no problem to just continually replace a single blob at the top level. Testing with git@vger history (https://public-inbox.org/git/ at 10066bdacf246bf885f7a11d06a5a87946d7af73 <20180208172153.GA30760@tor.lan> by Torsten Bögershausen @ Thu Feb 8 18:21:53 2018 +0100) For the 2-2-36 and 2-2-36 trees I took into account naming the last 16-bytes since that's what git.git uses for sorting/grouping for packing (pack_name_hash in pack-objects.h) 2-38 914M (baseline) 2-2-2-34 849M 2-2-36 832M 1-file 839M 2-2-2-34 has the most trees, so it's not great in terms of space. 2-2-36 optimizes deltas better than the 1-file route; but not significantly so. It seems optimizing for deltafication isn't worth the effort... Timing "git rev-list --objects --all |wc -l" reveals much bigger differences. Timings are a bit fuzzy since (AFAIK) this is a shared system, but it's not really a contest: 2-38 ~5 minutes 2-2-2-34 ~30 seconds 2-2-36 ~30 seconds 1-file ~5 seconds Smaller trees are way faster :) The downside of this change is squashing history will no longer be possible; but it won't be needed for efficiency reasons. In other words, git scales infinitely well to deep history depths, but not to breadth of large trees[1]. Marking spam and handling message removals might be a little trickier as chronology will have to be taken into account... (will post more on this, later) I also considered storing messages in the commit object itself but that would be tougher to reconcile if rewriting git history is necessary for legal reasons (DMCA). [1] - we currently process history with --reverse to walk in chronological order to ease processing of message removals; but --reverse is has an O(n) cost associated with it so we should avoid it. The thread association logic should be robust enough to be time-independent. --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="1file-convert.perl" #!/usr/bin/perl -w # Copyright 2018 The Linux Foundation # License: AGPL-3.0+ use strict; use warnings; use Email::MIME; use Digest::MD5 qw(md5_hex); $| = 0; my $h = '[0-9a-f]'; my $state = ''; my $blob; my $suff; # 16 bytes for git hashing while () { if ($_ eq "blob\n") { $state = 'blob'; } elsif (/^commit /) { $state = 'commit'; } elsif ($state eq 'commit') { if (m{^(M 100644 :\d+) ${h}{2}/${h}{38}}o) { my ($pfx) = ($1); print "$pfx msg\n"; next; } if (/^data (\d+)/) { print $_; my $len = $1; if ($len) { my $tmp; read(STDIN, $tmp, $len) or die "read: $!\n"; print $tmp; } next; } } elsif ($state eq 'blob') { if (/^data (\d+)/) { my $len = $1; print $_; next unless $len; read(STDIN, $blob, $len) or die "read: $!\n"; print $blob; next; } } print $_; } --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2-2-36-convert.perl" #!/usr/bin/perl -w # Copyright 2018 The Linux Foundation # License: AGPL-3.0+ use strict; use warnings; use Email::MIME; use Digest::MD5 qw(md5_hex); $| = 0; my $h = '[0-9a-f]'; my $state = ''; my $blob; my $suff; # 16 bytes for git hashing while () { if ($_ eq "blob\n") { $state = 'blob'; } elsif (/^commit /) { $state = 'commit'; } elsif ($state eq 'commit') { if (m{^(M 100644 :\d+) (${h}{2})/(${h}{2})(${h}{36})}o) { my ($pfx, $x2, $x4, $x36) = ($1, $2, $3, $4); print "$pfx $x2/$x4/$x36.$suff\n"; next; } if (/^data (\d+)/) { print $_; my $len = $1; if ($len) { my $tmp; read(STDIN, $tmp, $len) or die "read: $!\n"; print $tmp; } next; } } elsif ($state eq 'blob') { if (/^data (\d+)/) { my $len = $1; print $_; next unless $len; read(STDIN, $blob, $len) or die "read: $!\n"; print $blob; my $mime = Email::MIME->new($blob); $suff = $mime->header('Subject'); utf8::encode($suff); # git uses the last 16 bytes for deltas $suff = substr(md5_hex(substr($suff, -16)), -16); next; } } print $_; } --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2-2-2-34-convert.perl" #!/usr/bin/perl -w # Copyright 2018 The Linux Foundation # License: AGPL-3.0+ use strict; use warnings; use Email::MIME; use Digest::MD5 qw(md5_hex); $| = 0; my $h = '[0-9a-f]'; my $state = ''; my $blob; my $suff; # 16 bytes for git hashing while () { if ($_ eq "blob\n") { $state = 'blob'; } elsif (/^commit /) { $state = 'commit'; } elsif ($state eq 'commit') { if (m{^(M 100644 :\d+) (${h}{2})/(${h}{2})(${h}{2})(${h}{34})}o) { my ($pfx, $x2, $x4, $x6, $x34) = ($1, $2, $3, $4, $5); print "$pfx $x2/$x4/$x6/$x34.$suff\n"; next; } if (/^data (\d+)/) { print $_; my $len = $1; if ($len) { my $tmp; read(STDIN, $tmp, $len) or die "read: $!\n"; print $tmp; } next; } } elsif ($state eq 'blob') { if (/^data (\d+)/) { my $len = $1; print $_; next unless $len; read(STDIN, $blob, $len) or die "read: $!\n"; print $blob; my $mime = Email::MIME->new($blob); $suff = $mime->header('Subject'); utf8::encode($suff); # git uses the last 16 bytes for deltas $suff = substr(md5_hex(substr($suff, -16)), -16); next; } } print $_; } --ew6BAiZeqk4r7MaW--