Avoid a redundant stat, and gather updates to a frag
into a single OMAP get/set.
Still could be heaps more efficient in the case of
many updates to the same dirs by adding in a little
cache and batching the updates.
Signed-off-by: John Spray <john.spray@redhat.com>
This is intended as a comparatively safe recovery
operation, where we compare the versions
of journalled dentries with backing store dentries,
and write into the backing store only when the
existing contents are older than the journal
or invalid.
Fixes: #9883
Signed-off-by: John Spray <john.spray@redhat.com>
This triggers with the new larger mon_globalid_prealloc value. It didn't
trigger on the existing cluster I tested on because it already had a very
large max.
Signed-off-by: Sage Weil <sage@redhat.com>
Glance has not completely moved to 'store' yet so we need to configure
the store in the DEFAULT section as well.
Fixes: #10478
Signed-off-by: Sébastien Han <sebastien.han@enovance.com>
100 ids (session 100 authentications) can be consumed quite quickly if
the monitor is being queried by the CLI via scripts or on a large cluster,
especially if the propose interval is long (many seconds). These live in
a 64-bit value and are only "lost" if we have a mon election before they
are consumed, so there's no real risk here.
Backport: giant, firefly
Reviewed-by: Joao Eduardo Luis <joao@redhat.com>
Signed-off-by: Sage Weil <sage@redhat.com>
Fix the way we parse the marker. Instead of specifying whether it's a
sharded or not sharded bucket, we pass a shard_id. If string itself
points to a singe shard, we'll use the passed shard_id, otherwise we'll
parse the string and determine the shard id by that. In this way when
referencing a single shard we can get the marker with either shard id
specified or not. This works with the non-shard case too.
Adjust the bilog listing function, set it to work with the new
interface. It was broken before, and there are multiple fixes to it.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
We were returning 'quorum_features' instead. This would lead to funny
and weird behavior. I hate funny.
Backport: emperor,firefly,giant
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
When we create a monitor we set a given number of compat features on
disk to clearly state the features a given monitor supports -- mostly to
break backward compatibility when such compatibility cannot be
guaranteed.
However, we may wish to toggle some features during runtime; e.g., wait
for all the monitors in the quorum to support a given feature before
flipping a switch and state that all monitors now require feature X.
We are already flipping those switches during runtime, but we weren't
allowing the monitor to set a subset of those features during mkfs.
While the initial approach worked fine with clusters being upgraded and
fresh clusters, it could become weird in a mixed-version environment.
Backport: emperor,firefly,giant
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
