in certain recovery scenarios, e.g., monitor database lost and rebuilt, and
the restored file system is expected to have the same ID as before.
+* CEPHFS: Rename the `mds_max_retries_on_remount_failure` option to
+ `client_max_retries_on_remount_failure` and move it from mds.yaml.in to
+ mds-client.yaml.in because this option was only used by MDS client from its
+ birth.
+
>=16.2.11
--------
std::pair<int, bool> Client::_do_remount(bool retry_on_error)
{
- uint64_t max_retries = cct->_conf.get_val<uint64_t>("mds_max_retries_on_remount_failure");
+ uint64_t max_retries = cct->_conf.get_val<uint64_t>("client_max_retries_on_remount_failure");
bool abort_on_failure = false;
errno = 0;
.set_default(0)
.set_description("number of seconds after which clients which have not responded to cap revoke messages by the MDS are evicted."),
- Option("mds_max_retries_on_remount_failure", Option::TYPE_UINT, Option::LEVEL_ADVANCED)
- .set_default(5)
- .set_description("number of consecutive failed remount attempts for invalidating kernel dcache after which client would abort."),
-
Option("mds_dump_cache_threshold_formatter", Option::TYPE_SIZE, Option::LEVEL_DEV)
.set_default(1_G)
.set_description("threshold for cache usage to disallow \"dump cache\" operation to formatter")
.set_default(false)
.set_description(""),
+ Option("client_max_retries_on_remount_failure", Option::TYPE_UINT, Option::LEVEL_ADVANCED)
+ .set_default(5)
+ .set_description("number of consecutive failed remount attempts for invalidating kernel dcache after which client would abort."),
+
// note: the max amount of "in flight" dirty data is roughly (max - target)
Option("fuse_use_invalidate_cb", Option::TYPE_BOOL, Option::LEVEL_ADVANCED)
.set_default(true)