Hi Rimas,
So, in theory, it shouldn't be that hard to have one or two master
servers hosting let's say, a terabyte of data, right?
It is not about having one or two servers hosting the files. It is about
more than 100 servers hosting files for millions of users (> 50000000
downloads since version 3).
I think what would make sense is the following:
1) to have a consistent directory structure (i.e. the location of this
version builds in this language should be predictable) on master
servers. While looking at our project page
[http://distribution.openoffice.org/files.html#sets], everything seems
very clear already: ALL QA'd localized binaries should go to
/localized/, while unQA'd files go to /extended/localized/. That makes
Unfortunately that's not true. All files released by native language
teams are distributed via ../localized or via ../extended/localized. I
have to use ../extended/localized because the regular mirror network
lacks about 10 GB to host these files. Bouncer has been modified to be
able to handle ../extended content.
sense. I guess our project's problem is that we failed to accept the
fact that with growing number of supported languages, the size of
/localized/ (and thus sets that include it) also grows. Maybe it's time
to face it...
By the way, currently /localized/ uses 19GB, meanwhile at least for the
last year the aforementioned page says it is about 30GB. I wonder how
The size of the regular mirror network has a size of about 30 GB. The
extended mirror network has more disk space.
QA'd builds got into /extended/localized/ at all... I just adjusted my
script to fetch this whole folder, so I hope to see how much all our
QA'd builds actually take up now.
Thank you. That's good.
2) for space-concerned mirrors to mirror localized builds selectively.
For example, in my mirror in Lithuania, I currently host all builds from
/localized/ and en-US, Lithuanian, Latvian, Polish, and Russian files
from /extended/. I could surely add more languages (esp. from
neighbouring countries) to the list if I face a demand. To help reduce
the headache for mirror admins, we could group localizations logically
into sets (and maybe subsets). E.g., the set I host could be a part of
"Eastern Europe" set.
3) this should work very well when combined with geographical mirror
allocation, since local mirrors would be getting most of the request for
certain language builds anyway. I think the number of servers in a given
country is proportional to the number of users in that country, so for
smaller countries it's OK to have less/slower servers, meanwhile bigger
and more advanced countries would have more and faster servers anyway.
Bouncer 2.0 has no Geo IP support. We're currently evaluating a
different load balancing solution (MirrorBrain) as an alternative.
From my POV, language packs are second class citizens. They take
additional time and effort to discover and install, and should not be
the only way to get OOo in your language.
If there were enough disk space on all mirror servers then this wouldn't
be a problem at all. We could easily provide more than 160 GB for each
milestone but that's not realistic.
Kind regards, Joost
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
