We did some major repair on the DB in the last few days. It wasn't corruption, it was a data retention issue. Three seti teams (including MacNN) were not thinning out data over time, and had accumulated 5 GB of redundant data. The thinning operation maxed out the DB box's RAID for 12+ hours, followed by precautionary regular repairs.
This should not have directly affected the Folding data, but I'm looking into it.
Thanks for reporting this. No one regularly checks the stats on various teams for errors, chances are we don't know of issues until someone reports it. The data retention issue may have been going on for six months before Scott noticed the DB had swelled from 7+ GB to ~13 GB.
Edit: Fixed. Several updates ago, the Stanford server showed OneMacGuy with a lower stats total than before. On Folding, this is not allowed during member matching (stats can't go down), so the stats engine assumed he'd left and another guy with the same name had joined.
This matching rule is intended to handle guys with duplicate names such as "Anonymous". It trips up on regular people when the project server glitches up.
This sort of hiccup on the project server side is very rare for Folding. It happens a bit more often on SETI (and did on dFold as well) so those projects allow a certain amount of slip between updates. That handles routine matching, but the less restrictive rules make duplicate-name matching a bit more prone to error.
Top
