Sophie

Sophie

distrib > Mageia > 4 > x86_64 > by-pkgid > a9861aac0977a468c7b077c3f480368d > files > 3

mirrorbrain-2.17.0-1.mga4.x86_64.rpm

The issues listed in this file should be moved into the main documentation.
http://mirrorbrain.org/faq/ has answers to some more general questions.



Q: What is the effect of the score values?
A: Higher score means a greater chance of being picked. Some kind of
   weighted randomization. In the end, it matters how it compares to the 
   other scores. i.e., if all server have a score of 30, there are picked  
   with the same frequency. If only one mirror has a given file, its score
   is meaningless.

   This should give a picture how the score values behave (output captured from a
   test program), comparing 3 scores:
   
    % ./rand.py 100000 100 100 100
   score:   100 count: 33279 (33%)
   score:   100 count: 33378 (33%)
   score:   100 count: 33343 (33%)
    % ./rand.py 100000 100 50 50 
   score:   100 count: 58148 (58%)
   score:    50 count: 20893 (20%)
   score:    50 count: 20959 (20%)
    % ./rand.py 100000 100 200 10 
   score:   100 count: 24359 (24%)
   score:   200 count: 73588 (73%)
   score:    10 count:  2053 (2%)
   
    % ./randint 100000 100 100 100
   score:   100 count: 33474 (33.47%)
   score:   100 count: 33118 (33.12%)
   score:   100 count: 33408 (33.41%)
                         (100.00%)
    % ./randint 100000 100 50 50  
   score:   100 count: 58301 (58.30%)
   score:    50 count: 20840 (20.84%)
   score:    50 count: 20859 (20.86%)
                         (100.00%)
    % ./randint 100000 100 200 10
   score:   100 count: 24620 (24.62%)
   score:   200 count: 73337 (73.34%)
   score:    10 count:  2043 (2.04%)
                         (100.00%)


   Or as a more real-life example, imagine that you have a mirror with
   score=50, and other mirrors in the same country with the following scores:
   150, 100, 100, 100, 100, 50, 50, 30 -- then you can estimate:

   50 / (150+100+100+100+100+50+50+30) = 0.7

   Thus, about 7% of requests will routed to the mirror.

   (However, remeber that mirrors are not always "complete", so they might not
   always be considered at all.)


Q: How often does the scan take place? What I am wondering is; if I chose to
   delete something, how long before the distribution server sees it? I
   would not want anyone to get an error when they try to download
   something.

A: Good question. For now, the "best" is to send a note that one is going to
   delete something... the  master site can then disable redirection to the 
   mirror, and re-enable it after a scan once they are done...

   A brute-force approach would be to make the server return a 404, or take it 
   offline for some minutes, because every (e.g.) 5 minutes the redirector 
   checks with a request to '/' that the host is alive,  and disables
   redirection if that returns an error. 
   Yes, too ugly.

   The plan is, to provide admin access to the redirector database, so 
   mirrors could
    * disable redirection themselves,
    * trigger a scan, and re-enable it
    * maybe even mark parts of the tree as deleted in the database, so 
      they can safely delete them without further action required.

   This could possibly solved to a satisfactory degree by more frequent 
   scanning, of random files, basically simulating a (very light) workload.



Q: What does "zrkadlo" mean?
A: mod_zrkadlo was the previous name of mod_mirrorbrain. "zrkadlo" is a word
   found when travelling in Slovakia in 2006. 'zrkadlo' is Slovakian for 'mirror',
   and comprises about 33% of my Slovakian vocabulary :)

   Here is a nice illustration: http://sk.wikiquote.org/wiki/Zrkadlo