著者: intrigeri 日付: To: The Tails public development discussion list 題目: Re: [Tails-dev] Cleaning IUKs and updating disk space requirements
for mirrors
Hi,
sajolida: > But right, mirror operators might not store all their stuff on SSD
> like we do.
You might be interested in learning that we do things in a bit more
sensible way: we store data that's rarely accessed, such as the data
served by our rsync server, on cheaper, rotating hard-drives.
Hopefully this helps you freak out less about this topic :)
> I'm also not super happy to ask for much more than what we need (right
> now three times more than what we use). But yeah, I guess that I'll bump
> the number to 30 GiB, write all mirror operators and see if that's an
> actual problem for some of them.
Agreed.
>>> 4. Make sure that we don't break them again silently in the
>>> future. Would it be complicated to check the size of the whole
>>> thing during the release process? I'll let the RMs tell me if it's
>>> worth the extra work.
>>
>> Sounds like a good idea! Where can I find an always up-to-date list
>> of what directories that are mirrored (IIRC not all of the ones in
>> our rsync directory are)? Then I can cook up a command that uses that
>> list to calculate the current mirror disk usage. > I always forgot how our uploading mechanism work as I never interact
> with it myself. But if you are not sure yourself about how to compute
> this number easily then it probably means that this idea is more
> complicated than it should and that we should drop it :)
It's actually very simple: everything is mirrored.
We still tell mirror operators that they can exclude the "obsolete"
directory if they wish, but we've deleted it on our side months ago,
so I'm going to drop these bits from the doc.
So, anonym: please either do this immediately after reading this
email, or give yourself a ticket so we don't forget about it.
I also thought that a monitoring check might be useful, but IMO it's
overkill as we can solve this much more easily, and closer to where it
should be fixed if a problem is found, in the release process doc.
