fjall-rs/fjall

Is your feature request related to a problem? Please describe. Currently, configuration parameters like .staleness_threshold() and .age_cutoff() are persistently serialized and hardcoded into the internal System Keyspace metadata upon initialization. Because of this design, these parameters become completely immutable. Even if we modify the configuration values in the code and rebuild or restart the system, the database entirely ignores the new code settings and strictly adheres to the original values fetched from the System Keyspace. If a user initially sets suboptimal thresholds and later faces critical disk space pressure, they are completely locked out from adjusting the cleanup intensity. Since these parameters only dictate the background GC/compaction heuristic logic and do not alter the core data format (unlike block size), locking them into the System Keyspace permanently creates an unnecessary and rigid limitation. Describe the solution you'd like I would like to make these co

Describe the bug We've noticed that our application tends to accumulate journal segments; every once in a while, a sealed journal will get "stuck" and won't get cleared after recovery. Once this happens, of course, no subsequent sealed journals can ever get cleared so the journal size grows without bound until the application gets so bloated that startup can't finish within the kubernetes startup probe timeout and it breaks. In the cases I've examined, the journal contains a record pointing to a keyspace that isn't actively being used on this instance, whose memtable is empty. In this case, the table can never be flushed (the super_version.active_memtable.is_empty() call in lsm-tree return false), so we can never actually increase the persisted seqno and never get the journal out. One possible way to create this scenario is to make a call to clear() for a keyspace, but do no subsequent writes. It's still tricky to do this because you need to end up sealing that journal (so you need to

I'm working on an application which sometimes streams entire keyspaces between nodes. This works fine today (the sender just iterates all the keys and the receiver puts them in place), but there seems to be no way for me to get the KeyspaceCreateOptions for a given keyspace and forward them along. I can modify my application to handle this (by, say, serializing the create options as a specially-named key at keyspace creation time), but this isn't ideal and I'd love an API to introspect the KeyspaceCreateOptions from an existing keyspace. I know there's .is_kv_separated() but I didn't see any other APIs to introspect keyspaces. Thanks!