-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Labels:
-
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)?