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

Fix/add tiered storage statistics for URIs

    • StorEng - Refinement Pipeline

      With this change:

      diff --git a/test/suite/test_tiered04.py b/test/suite/test_tiered04.py
      old mode 100644
      new mode 100755
      index 87252ade9..ec81d4ccd
      --- a/test/suite/test_tiered04.py
      +++ b/test/suite/test_tiered04.py
      @@ -120,6 +120,9 @@ class test_tiered04(wttest.WiredTigerTestCase, TieredConfigMixin):
               self.check(cn, 0, 1)
               c.close()
       
      +        self.assertGreater(self.get_stat(stat.dsrc.block_size, "file:WiredTiger.wt"), 0)
      +        self.assertGreater(self.get_stat(stat.dsrc.block_size, self.uri), 0)
      +
               flush = 0
               # Check the local retention. After a flush_tier call the object file should exist in
               # the local database. Then after sleeping long enough it should be removed. 

      I get this:

      [1661264853:788327][24420:0x7f13b0f83740], test_tiered04.test_tiered04.test_tiered(dirstore), WT_SESSION.open_cursor: [WT_VERB_DEFAULT][ERROR]: __wt_object_unsupported, 729: unsupported object operation: statistics:tiered:test_tiered04: Operation not supported

      That's on the second call.  And what's failing is the open_cursor, using uri "table:test_tiered04".

      It does seem like we should allow the cursor to be opened, but what statistics should be reported?  By concealing some magic in the wiredtiger_open call, a "traditional" program is converted to use tiering for all tables.  We could continue the illusion and report the various block/btree statistics.  Would they be for the local table?  (probably easy)  Or an aggregation for all objects?  (harder).

      Can individual objects be queried (uri == "object:test_tiered-0000074.wtobj")?

      Are there per object or per table statistics related to all the various things in tiered storage (network activity/failures, compression, GC)?

            Assignee:
            sue.loverso@mongodb.com Susan LoVerso
            Reporter:
            donald.anderson@mongodb.com Donald Anderson
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: