Mon, 24 Mar 2014 15:43:15 -0700 fncache: clean up fncache during strips
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:43:15 -0700] rev 20885
fncache: clean up fncache during strips Previously the fncache was cleaned up at read time by noticing when it was out of sync. This caused writes to happen outside the scope of transactions and could have caused race conditions. With this change, we'll keep the fncache up-to-date as we go by removing old entries during repair.strip.
Mon, 24 Mar 2014 15:35:07 -0700 caches: invalidate store caches when lock is taken
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:35:07 -0700] rev 20884
caches: invalidate store caches when lock is taken The fncache was not being properly invalidated each time the lock was taken, so in theory it could contain old data from prior to the caller having the lock. This changes it to be invalidated as soon as the lock is taken (same as all our other caches).
Mon, 24 Mar 2014 15:42:13 -0700 fncache: move fncache writing to be in a transaction
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:42:13 -0700] rev 20883
fncache: move fncache writing to be in a transaction Previously the fncache was written at lock.release time. This meant it was not tracked by a transaction, and if an error occurred during the fncache write it would fail to update the fncache, but would not rollback the transaction, resulting in an fncache that was not in sync with the files on disk (which causes verify to fail, and causes streaming clones to not copy all the revlogs). This uses the new transaction backup mechanism to make the fncache transacted. It also moves the fncache from being written at lock.release time, to being written at transaction.close time.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip