Re: ftpsync README rewrite
On 11874 March 1977, Lee Winter wrote:
> So in the mean time I have accomplished two things. I analyzed the
> debian subsections with an eye to writing up a tuning article on
> mirror admin.
This you will never see in ftpsync. It isnt meant for such broken
setups. (As soon as you have more than yourself using the mirror the
assumption of which section applies is almost always wrong).
You have to use debmirror for this.
> E.g., if your uplink is a 56Kbps link with a 30% duty cycle and you
> live under a triple canopy forest teaching elementary school you may
> not have much use for the devel or electronics subsections. But there
> is not enough information available about what including or excluding
> a particular subsection costs in space and bandwidth. For 5.03 the
> space numbers are as follows (a/o 2009-09-12):
It will be very disappointing for you (or your users) if you do it. A
package might not be in the section you think it would, simply cos it
would fit multiple and the maintainer or ftpmaster selected another.
Also, sections are doomed to go away, so building a mirror based on them
is already walking on a blind alley.
> However, I see no simple way to compute that over a reasonable sample
> period, like a month, without a serious investment in package tools.
> Do they aready exist?
http://ftp-master.debian.org/size-quarter.png
Thats complete Debian, so we have updates between 2 and 6GB, 4 times a
day.
> The other thing I accomplished is to find a way to eliminate the load
> that rsync imposes on upstream mirrors. IMO it would not take much
> work to tweak rsync and adjust the calling scripts so that the
> upstream mirrors could be completely passive.
If you find a way that actually works nicely I am MOST interested to
learn it!
Note that the rsync batch thingie it offers does not work for us.
We need to keep in mind that our mirrors:
- simply update everything. That can easily be done with current rsync
features, by us writing a batch file for it.
Combined with a detection if they missed an update or not, it would
be something doable.
- update a subset only. And that subset can either be the "typical" foo
we offer, or any combination of architectures you can imagine.
The latter is what kills.
--
bye, Joerg
<exa> There is no point in trying to fix bugs if I won't have an
account. Sorry.
Reply to: