Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-2089

checkpoint and clean-page eviction race

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT2.7.0
    • Labels:
      None
    • # Replies:
      16
    • Last comment by Customer:
      true

      Description

      Michael Cahill, I've been staring at the code that checks WT_PM_REC_MULTIBLOCK in __wt_page_can_split and __wt_page_can_evict, and I'm unclear on a couple of things.

      First, it seems to me we're safe with respect to in-memory splits of pages where WT_PM_REC_MULTIBLOCK is set: the in-memory split of the parent page acquires the parent/internal page's WT_PAGE_RECONCILIATION lock, which will block out checkpoint's reconciliation of the page. However, we're potentially exercising a complicated error path when the split collides with the checkpointing thread and the split unrolls itself: we might want to make sure we're testing that error path more than casually, or alternatively, acquire the parent's reconciliation lock earlier, before we're so deeply committed.

      Second, I don't think we're safe with respect to eviction of any page that will update an internal page, during a checkpoint (and that's any page where any WT_PAGE_MODIFY.flag value is set, not just WT_PM_REC_MULTIBLOCK. Here's the scenario:

      1. Start a checkpoint,
      2. The checkpoint reconciles an internal page, and finds child page X, reads WT_REF.state == WT_REF_MEM and WT_PAGE_MODIFY.flags == WT_PM_REC_REPLACE, then sleeps.
      3. Then evict page X because it's clean and WT_PM_REC_MULTIBLOCK isn't set. That ends up in __evict_page_dirty_update, where we replace WT_REF.addr with WT_PAGE_MODIFY.mod_replace, and clear that value.
      4. The checkpoint then wakes up, and based on its reading of WT_PAGE_MODIFY.flags, reads WT_PAGE_MODIFY.mod_replace.

      Hopefully I'm just missing something...

        Issue Links

          Activity

          Hide
          keith.bostic Keith Bostic added a comment -

          That's what the code will currently do – it would be good to update the comment checking for dirty pages in wt_page_can_split to make it clear that we're relying on this for correctness.

          I'll push that change – alternatively, we could dirty the page explicitly in wt_split_insert?

          I believe PR#2719 is ready for review & merge.

          Show
          keith.bostic Keith Bostic added a comment - That's what the code will currently do – it would be good to update the comment checking for dirty pages in wt_page_can_split to make it clear that we're relying on this for correctness. I'll push that change – alternatively, we could dirty the page explicitly in wt_split_insert ? I believe PR#2719 is ready for review & merge.
          Hide
          keith.bostic Keith Bostic added a comment -

          Before closing this ticket: review wt_split_multi and wt_split_insert, make sure page accounting (for example), is correct after the in-memory split returns EBUSY, because we're going to see those failures in the field.

          Show
          keith.bostic Keith Bostic added a comment - Before closing this ticket: review wt_split_multi and wt_split_insert , make sure page accounting (for example), is correct after the in-memory split returns EBUSY, because we're going to see those failures in the field.
          Hide
          xgen-internal-githook Githook User added a comment -

          Author:

          {u'username': u'keithbostic', u'name': u'Keith Bostic', u'email': u'keith@wiredtiger.com'}

          Message: WT-2089: relax the restriction on evicting pages, previous reconciled
          into multiple blocks, during checkpoint.
          Branch: develop
          https://github.com/wiredtiger/wiredtiger/commit/27cc8c58e7115b7419024aad890fd38d54756db7

          Show
          xgen-internal-githook Githook User added a comment - Author: {u'username': u'keithbostic', u'name': u'Keith Bostic', u'email': u'keith@wiredtiger.com'} Message: WT-2089 : relax the restriction on evicting pages, previous reconciled into multiple blocks, during checkpoint. Branch: develop https://github.com/wiredtiger/wiredtiger/commit/27cc8c58e7115b7419024aad890fd38d54756db7
          Hide
          xgen-internal-githook Githook User added a comment -

          Author:

          {u'username': u'keithbostic', u'name': u'Keith Bostic', u'email': u'keith@wiredtiger.com'}

          Message: WT-2089: relax the restriction on doing in-memory splits on pages
          previous reconciled into multiple blocks.
          Branch: develop
          https://github.com/wiredtiger/wiredtiger/commit/8552e0686fed97ae325b42091d64fce89730eb0b

          Show
          xgen-internal-githook Githook User added a comment - Author: {u'username': u'keithbostic', u'name': u'Keith Bostic', u'email': u'keith@wiredtiger.com'} Message: WT-2089 : relax the restriction on doing in-memory splits on pages previous reconciled into multiple blocks. Branch: develop https://github.com/wiredtiger/wiredtiger/commit/8552e0686fed97ae325b42091d64fce89730eb0b
          Hide
          xgen-internal-githook Githook User added a comment -

          Author:

          {u'username': u'michaelcahill', u'name': u'Michael Cahill', u'email': u'michael.cahill@mongodb.com'}

          Message: Merge pull request #2179 from wiredtiger/wt-2089-multiblock-checkpoint

          WT-2089 relax restrictions on multiblock eviction, in-memory splits
          Branch: develop
          https://github.com/wiredtiger/wiredtiger/commit/334e10321f53763ca5f07089e9f4b60effaca83f

          Show
          xgen-internal-githook Githook User added a comment - Author: {u'username': u'michaelcahill', u'name': u'Michael Cahill', u'email': u'michael.cahill@mongodb.com'} Message: Merge pull request #2179 from wiredtiger/wt-2089-multiblock-checkpoint WT-2089 relax restrictions on multiblock eviction, in-memory splits Branch: develop https://github.com/wiredtiger/wiredtiger/commit/334e10321f53763ca5f07089e9f4b60effaca83f

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since reply:
                1 year, 41 weeks, 6 days ago
                Date of 1st Reply: