liucao-dd commented on code in PR #206:
URL:
https://github.com/apache/cassandra-analytics/pull/206#discussion_r3325732353
##########
cassandra-analytics-common/src/main/java/org/apache/cassandra/spark/data/FileType.java:
##########
@@ -83,4 +83,15 @@ public String getFileSuffix()
{
return fileSuffix;
}
+
+ /**
+ * Whether the on-disk size of this component can drift from the value
recorded in a backup
+ * manifest. Cassandra rewrites Summary/Filter/Statistics in place during
compaction, so a
+ * stale manifest size for these components can produce truncated
ranged-GETs against the
+ * backing store. The data layer treats these components specially when
issuing reads.
+ */
+ public boolean isMutableMetadata()
+ {
+ return this == SUMMARY || this == FILTER || this == STATISTICS;
Review Comment:
Good catch, i think filter.db is theoretically immutable but there is a code
path that re-writes it:
https://github.com/apache/cassandra/blob/45fa31b/src/java/org/apache/cassandra/io/sstable/format/SSTableReaderBuilder.java#L450
It should be very rare, and if I read the code correctly, it happens during
live re-opens of an SSTable (startup, import, streaming receipt), and only when
its Filter.db is missing or it has no ValidationMetadata.
So it is theoretically possible but most likely can be treated immutable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
