Jeff / Duy,
Fixes since v2.4
* Access to objects in repositories that borrow from another one on a
slow NFS server unnecessarily got more expensive due to recent code
becoming more cautious in a naive way not to lose objects to pruning.
(merge ee1c6c3 jk/prune-mtime later to
On Sunday, May 24, 2015 @ 10:01 AM Duy Nguyen [mailto:pclo...@gmail.com] did
scribble:
In case you want to back away from option 2 because it starts to leak
raciness, which your old commit tried to fix in the first place. I
think the only other place that tests for lots of non-existent loose
On Friday, June 05, 2015 @ 1:18 PM Jeff King [mailto:p...@peff.net] did
scribble:
Sorry, I haven't had a chance to look at it further. It still on my todo
list. My plan is:
1. Devise some torture to tests to see whether my patch series is in
fact racy on Linux.
2. Assuming it
On Friday, May 22, 2015 @ 8:12 AM Jeff King did scribble:
In builtin/index-pack.c, replace the line collision_test_needed =
has_sha1_file(sha1); with collision_test_needed = 0;. Security is
compromised but for this test it should be ok. Then clone again. I
hope the new number gets down
On Friday, May 22, 2015 @ 11:06 AM Duy Nguyen did write:
Strange. Maybe there is something else... Anyway some numbers from me.
This is nfs3 hosted by Raspberry Pi, accessed over wireless. I just
run index-pack on git.git pack instead of full clone.
- v1.8.4.1 34s
- v1.8.4.2 519s (oh..
In setting up some new git servers I was trying to test the performance of some
NFS mounted volumes and when compared to local disk (although this is a
vitualized server so not truly local) cloning to NFS was taking a long time.
Here are some timings:
~ $ time bin/git clone
On Thu, May 21, 2015a at 9:31 PM, Duy Nguyen [mailto:pclo...@gmail.com], did
scribble:
In case an object is not found pack directory is re-read again, which
might cause some increased load on nfs.
has_sha1_file() not finding the object should not happen often..
That last statement is
7 matches
Mail list logo
