#9321: Load balance right when we have higher guard rotation periods -------------------------+------------------------------------------------- Reporter: arma | Owner: Type: project | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor | Version: Resolution: | Keywords: needs-proposal, tor-auth, tor- Actual Points: | client, 026-triaged-1 Points: | Parent ID: #11480 -------------------------+-------------------------------------------------
Comment (by nickm): Replying to [comment:22 asn]: [...] > Then 5 minutes before the hour, little-t-tor will read the guardiness output file and consider its data when voting. This all seems plausible; can any dirauth ops comment on whether this is a reasonable thing to set up? > Some notes: > > * Instead of downloading the latest consensus from metrics, maybe we could add little-t-tor code that would save new consensuses into a directory. This way, we don't need to download bulk from metrics, apart from during the bootstrap procedure. This seems plausible and not terribly hard. The only thing to deal with here would be getting rid of old files. (see below.) I guess you could have a "KeepOldConsensuses 90 days" option along with "OldConsensusDir /var/xyzzy" that would store the last 90 days of consensuses in some directory of your choice. > * To avoid keeping old summary/consensus files around that take over disk space, I added some optional cleanup switches to the scripts. Specifically, the `summizer.py` script can delete the consensus files that got summarized and can also delete consensus files older than 3 months (or N months). Similarly, the `guardiness.py` script can delete summary files older than 3 months (or N months). The idea is that every time the cron job triggers, the `summizer.py` and `guardiness.py` scripts will auto- delete the oldest summary/consensus file, keeping in disk only the useful files. This also seems plausible. Except instead of deleting the oldest unconditionally, it's probably best for them to delete any consensus whose valid-until time is more than N days before the current time. That way, if you have to re-run them, or if you mess up mtimes on your disk, they don't wind up deleting things they shouldn't. (Do you have more questions? If so, please make sure they end with a ? or I am likely not to realize that they are questions. :) ) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9321#comment:23> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs