You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A leveldb snapshot (created independently or as part of a database iterator) locks a set files on the disk. The files are part of some Version object, but not necessarily the most current Version. Therefore the logical disk size of the current Version can be greatly exceeded by the actual size of all files locked via snapshots.
Recent compaction selection logic that better supports tiered storage only uses logical disk size of current Version. It is therefore possible for a snapshot(s) to hold enough data in the fast tier to cause the fast tier to overflow. Compaction selection logic could greatly help in this overflow scenario if it used total space used by all Versions. (Remember that some files may appear in more than one version.)
The text was updated successfully, but these errors were encountered:
Basho-JIRA
changed the title
Track level size by current version, or all versions?
Track level size by current version, or all versions? [JIRA: RIAK-2496]
Apr 12, 2016
A leveldb snapshot (created independently or as part of a database iterator) locks a set files on the disk. The files are part of some Version object, but not necessarily the most current Version. Therefore the logical disk size of the current Version can be greatly exceeded by the actual size of all files locked via snapshots.
Recent compaction selection logic that better supports tiered storage only uses logical disk size of current Version. It is therefore possible for a snapshot(s) to hold enough data in the fast tier to cause the fast tier to overflow. Compaction selection logic could greatly help in this overflow scenario if it used total space used by all Versions. (Remember that some files may appear in more than one version.)
The text was updated successfully, but these errors were encountered: