Le 3/13/13 10:47 AM, Kiran Ayyagari a écrit : > On Wed, Mar 13, 2013 at 2:55 PM, Emmanuel Lécharny <elecha...@gmail.com>wrote: > >> Le 3/12/13 6:34 PM, Kiran Ayyagari a écrit : >>> On Tue, Mar 12, 2013 at 10:23 PM, Emmanuel Lécharny <elecha...@gmail.com >>> wrote: >>> >>> >>> 3) if the two revisions are different, that means we had a crash: we >>>> will have to read all the pages, and discard the pending N+1 revision >>>> pages. >>>> >>>> I would suggest that we keep the revisions N-1 and N >>> and during each update the N-1 will be replaced with N and N with N+1 >>> as long as the difference between revisions is 1 we can assume that there >>> was no crash. >>> In case of a crash we can start with the existing N-1 revision as the >> base >>> to recover >> If we assume that revision N was ok, we can always recover from it. The >> pending N+1 revision just means we are not clean with the new revision. >> >> The status will be : >> >> T0 : N and N >> T1 (starting with a new revision : N and N+1 >> T2 (done with the new revision) : N+1 and N+1 -> back to a stable state >> >> I have a little trouble to map what you propose on a time line : >> >> T0 : N-1 and N >> T1 (starting with a new revision) : N-1, N and N+1 (is this correct ?) >> T2 (done with the new revision) : N and N+1 >> >> the time line would be > T0 : N-1 and N > T1 (starting with a new revision) : N and NULL (replace N-1 with N and make > the current revision as NULL, cause it is ongoing) > T2 (done with the new revision) : N and N+1 (update the current version to > N+1 _after_ updating the BTree)
Thinking about it a second time, I'm not even sure that we need this second revision at all : assuming the update of the header will be eitehr done or not, on startup, we can be sure that the stored revision points to a valid BTree. The key here is to be able to detect that we have some pending modification (and thus some pages that have already been written, but not associated with the current BTree) on the disk, and we need to reclaim those pages. This is why I was suggesting adding the revision for the pending new BTree beside the current revision : when w are done updating the new BTree, we simply make it the current revision. Otherwise, both solution will work. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com --------------------------------------------------------------------- To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org For additional commands, e-mail: labs-h...@labs.apache.org
