Details
-
Bug
-
Status: Open
-
Major - P3
-
Resolution: Unresolved
-
None
-
None
-
None
-
StorEng - Refinement Pipeline
Description
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)?