Bug #64511
open
kv/RocksDBStore: rocksdb_cf_compact_on_deletion has no effect on the default column family
Added by Joshua Baergen 3 months ago.
Updated about 19 hours ago.
Backport:
quincy reef squid
Description
This setting is applied via update_column_family_options(), which is called for each configured CF but not for the default one (at least for upgraded systems that have not been resharded - I could be misunderstanding the flow for resharded/new systems). This is a big deal for upgraded systems since the bulk of rocksdb data lives in the default CF.
Related issues
3 (3 open — 0 closed)
- Status changed from New to Fix Under Review
- Pull request ID set to 55676
- Project changed from RADOS to bluestore
- Status changed from Fix Under Review to Pending Backport
- Target version set to v20.0.0
- Source set to Community (user)
- Backport set to quincy reef squid
- Affected Versions v16.2.15, v18.2.3 added
- Affected Versions deleted (
v16.2.14, v18.2.0, v18.2.1)
Hi,
Will this fix get into 18.2.3 ?, thanks
Steven Goodliff wrote in #note-4:
Hi,
Will this fix get into 18.2.3 ?, thanks
Seems, backport bot is broken. The backport issues wasn't crated for a days
will someone fix the backport bot ?, were thinking about upgraded to a version that has this fix in hence the question. Thanks
- Copied to Backport #65914: quincy: kv/RocksDBStore: rocksdb_cf_compact_on_deletion has no effect on the default column family added
- Copied to Backport #65915: squid: kv/RocksDBStore: rocksdb_cf_compact_on_deletion has no effect on the default column family added
- Copied to Backport #65916: reef: kv/RocksDBStore: rocksdb_cf_compact_on_deletion has no effect on the default column family added
- Tags set to backport_processed
Steven Goodliff wrote in #note-6:
will someone fix the backport bot ?, were thinking about upgraded to a version that has this fix in hence the question. Thanks
I was make some noise on dev list, Casey pushed backports now
Thanks guys, much appreciated
Also available in: Atom
PDF