| 1 |
On Wed, 28 Jul 2004 19:09:20 +0000, Sri Gupta <sri@×××××.com> wrote: |
| 2 |
|
| 3 |
> Does rsync support push updates? I'm sure you could cronjob it, but it might |
| 4 |
> just be easier to export /usr/portage over NFS. No need to worry about replication. |
| 5 |
|
| 6 |
I have done this, and still do it to an extent, and it does work, but |
| 7 |
there are some caveats. |
| 8 |
|
| 9 |
When you emerge sync, rsync has to crawl the entire local copy of the |
| 10 |
tree. If this on an NFS-mounted filesystem, that means it has to stat |
| 11 |
every single file, and there is latency involved with this. I have a |
| 12 |
Portage tree that's on a NetApp Filer, and it is slow to update, |
| 13 |
several times slower than local disk (in this case, two 320 MB/s SCSI |
| 14 |
drives in RAID-1). However, if your rsync server is also your NFS |
| 15 |
server, this isn't an issue. When my rsync server was serving the tree |
| 16 |
off an NFS filesystem, it was really slow: Only a couple hundred files |
| 17 |
per second on the file list. The machine above can push down the file |
| 18 |
list (some 90K files) in about 4 seconds. |
| 19 |
|
| 20 |
Another issue is that the first emerge after the NFS-mounted Portage |
| 21 |
tree has been updated can be a bit slow, because it has to rebuild the |
| 22 |
cache for any updated ebuilds. Normally emerge sync does this, but if |
| 23 |
you have an NFS-mounted Portage tree, you never run emerge sync. |
| 24 |
|
| 25 |
So yes, you can do it, and there are no real showstopper issues, but |
| 26 |
you'll get better performance with a local disk Portage tree at the |
| 27 |
cost of 100 MB or so. If disk space is a real issue and you aren't |
| 28 |
picky about how long it takes, the NFS solution works well. |
Archives