| 1 |
On Sun, 16 Dec 2018 06:34:07 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> My guess is that it will |
| 5 |
> also cost more IO server-side than rsync, |
| 6 |
|
| 7 |
Surely that's dependent on how much of the rsync mirror is retained in |
| 8 |
the VFS cache, and how efficiently the server in question avoids paging. |
| 9 |
|
| 10 |
To the best of my understanding, server-side of rsync requires IO on |
| 11 |
*thousands* of files, (lots of stat, open(), checksum), whereas |
| 12 |
server-side for git can be reduced to only a handful of large files |
| 13 |
(packs). |
| 14 |
|
| 15 |
Even if we assume in both cases everything needed fits in VFS cache, |
| 16 |
the rsync option still has reams of stat and open syscalls, that the |
| 17 |
git option avoids, surely. |
| 18 |
|
| 19 |
( My observations made with vmtouch indicate that git doesn't even need |
| 20 |
to load the entire pack into memory for a large majority of operations ) |
Archives