the Journla snapshot is not a true snapshot, in that the active file in the snapshot can still be taking appends. So when getting a snapshot it is necessary to check if folding over the snapshot that the SQN is <= JournalSQN when the snapshot is taken.
Normally consistency of the snapshot is managed as the operation depends on the penciller, and the penciller *is* a snapshot. Not in this case, as the penciller will return true on a sqn check if the pcl SQN is behind the Journal. So the Journal folder, has been given an additionla check to stop at the JournalSQN.
This is perhaps a fault in the pcl check sqn, which should only return true on an exact match? I'm nervous about changing this though, so we have a less pure fix for now.
These logs duplicate information being received from other logs, so reduced to debug.
The long running test needs to change with the LONG_RUNNING macro
This test (prior tot his commit) works fine. However, something about running it with riak `make test` causes it to fail. The process crashes when the file:delete(F2) is called.
As the test works in isolation on R16, and also because aprocess crashing in the real world in this stage would not be the end of the world (this whole part was added as a way of dealing with some unlikely but possible tidy-up scenarios in eqc tests), losing the test in R16 is tolerable.
So In R16 tests (which includes riak make test), the delete will no longer be called in this test.
Confirm it results in many more files, if the slot count reduced. Has to handle the fact that Level 0 file has unlimited slots regardless of number of slots configured
The inker cler will now close compacted files before prompting the inker to update the manifest. The inker should reopen those files, so that the file processes are linked to it and not the clerk.
This also stops a stopped clerk leading to orphaned cdb files.
This allows for leveled_iclerk:clerk_stop to be a sync call, so that files will only be closed once the iclerk has stopped. This is designed ot prevent iclerk crashes during shutdowns when files it is depnding on are closed mid shutdown.
Warn at startup if this ratio is high. Not sure how snapshots will perform if there are a lot of ledger cache sin the list. However, it should still work. basic_SUITE/load_count test intended to demonstrate that a large ratio is still functional
A test thta will cause leveled to crash due to a low cache size being set - but protect against this (as well as the general scenario of the cache being full).
There could be a potential case where a L0 file present (post pending) without work backlog being set. In this case we want to roll the level zero to memory, but don't accept the cache update if the L0 cache is already full.
