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

LSM modifying chunks after switch

    • Type: Icon: Task Task
    • Resolution: Done
    • WT2.2.1
    • Affects Version/s: None
    • Component/s: None
    • None

      It appears as though LSM is still modifying chunks after they should be stable:
      http://mjc.homeunix.org:8180/job/wiredtiger-test-format-stress-lsm/1/console

      From the core file:

      (gdb) where
      #0  0x0000003467632925 in raise () from /lib64/libc.so.6
      WT-1  0x0000003467634105 in abort () from /lib64/libc.so.6
      WT-2  0x00000000004af34b in __wt_abort (session=0x272a660)
          at ../src/os_posix/os_abort.c:24
      WT-3  0x0000000000446fb0 in __wt_assert (session=0x272a660, error=0, 
          file_name=0x6743b7 "../src/include/btree.i", line_number=391, 
          fmt=0x674321 "%s") at ../src/support/err.c:452
      WT-4  0x0000000000482da8 in __wt_page_modify_set (session=0x272a660, 
          page=0x7f56e00ffa30) at ../src/include/btree.i:391
      WT-5  0x0000000000483297 in __wt_insert_serial (session=0x272a660, 
          page=0x7f56e00ffa30, ins_head=0x7f569403ae00, ins_stack=0x7f56941917b8, 
          new_insp=0x7f5720db99e8, new_ins_size=102, skipdepth=1)
          at ../src/include/serial.i:267
      WT-6  0x0000000000483a44 in __wt_row_modify (session=0x272a660, 
          cbt=0x7f5694191670, key=0x7f5694191738, value=0x7f5694191760, 
          upd=0x7f5694167090, is_remove=0) at ../src/btree/row_modify.c:168
      WT-7  0x00000000004c2dd2 in __cursor_row_modify (session=0x272a660, 
          cbt=0x7f5694191670, is_remove=0) at ../src/btree/bt_cursor.c:252
      WT-8  0x00000000004c371e in __wt_btcur_insert (cbt=0x7f5694191670)
          at ../src/btree/bt_cursor.c:482
      WT-9  0x00000000004920d5 in __curfile_insert (cursor=0x7f5694191670)
          at ../src/cursor/cur_file.c:223
      WT-10 0x00000000004a8a9e in __clsm_put (session=0x272a660, clsm=0x7f5694063ef0, 
          key=0x7f5694063fb8, value=0x7f5720db9c50, position=0)
          at ../src/lsm/lsm_cursor.c:1234
      WT-11 0x00000000004a9319 in __clsm_insert (cursor=0x7f5694063ef0)
          at ../src/lsm/lsm_cursor.c:1345
      WT-12 0x000000000041163f in row_insert (cursor=0x7f5694063ef0, 
          key=0x7f5720db9e10, value=0x7f5720db9de0, keyno=25953)
          at ../../../test/format/ops.c:895
      (gdb) p clsm->primary_chunk
      $14 = (WT_LSM_CHUNK *) 0x7f56e001dbb0
      (gdb) p lsm_tree->chunk[lsm_tree->nchunks - 1]
      $15 = (WT_LSM_CHUNK *) 0x7f56e001dbb0
      (gdb) p *clsm->primary_chunk
      $16 = {uri = 0x7f56e0001880 "file:wt-000013.lsm", bloom_uri = 0x0, 
        create_ts = {tv_sec = 1402900173, tv_nsec = 277243912}, count = 13634, 
        size = 3121152, txnid_max = 308665, update_txn_max = 0, id = 13, 
        generation = 0, refcnt = 2, bloom_busy = 0, empty = 0 '\000', 
        evicted = 0 '\000', flags = 0}
      

      The operation in the put is happening on what the LSM tree thinks is still the primary chunk.

      Digging a bit deeper, the WT_LSM_TREE_FLUSH_ALL flag is set:

      (gdb) p /x lsm_tree->flags
      $2 = 0x3a
      (gdb) thread apply all where
      ...
      Thread 13 (Thread 0x7f56c3fff700 (LWP 28501)):
      #0  0x00000034676e15e3 in select () from /lib64/libc.so.6
      WT-1  0x00000000004313e1 in __wt_sleep (seconds=1, micro_seconds=0)
          at ../src/os_posix/os_sleep.c:22
      WT-2  0x0000000000429b76 in __wt_lsm_compact (session=0x272dd60, 
          name=0x7f56ac08f110 "lsm:wt", skip=0x7f56c3ffec6c)
          at ../src/lsm/lsm_tree.c:1049
      WT-3  0x000000000043fcc7 in __wt_schema_worker (session=0x272dd60, 
          uri=0x7f56ac08f110 "lsm:wt", file_func=0, 
          name_func=0x429a4b <__wt_lsm_compact>, cfg=0x7f56c3ffed90, open_flags=0)
          at ../src/schema/schema_worker.c:37
      

            Assignee:
            Unassigned Unassigned
            Reporter:
            alexander.gorrod@mongodb.com Alexander Gorrod
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: