mirror of
https://github.com/ceph/ceph
synced 2024-12-18 17:37:38 +00:00
3321cc7b37
Right now, we have two different timeout settings -- one for when the client is just not responding at all (mds_session_timeout), and one for when the client is otherwise responding but isn't returning caps in a timely fashion (mds_cap_revoke_timeout). The default settings on them are equivalent (60s), but only the mds_session_timeout is communicated via the mdsmap. The mds_cap_revoke_timeout is known only to the MDS. Neither timeout results in anything other than warnings in the current codebase. There is also a third setting (mds_session_autoclose) that is also communicated via the MDSmap. Exceeding that value (default of 300s) could eventually result in the client being blacklisted from the cluster. The code to implement that doesn't exist yet, however. The current codebase doesn't do any real sanity checking of these timeouts, so the potential for admins to get them wrong is rather high. It's hard to concoct a use-case where we'd want to warn about these events at different intervals. Simplify this by just removing the mds_cap_revoke_timeout setting, and replace its use in the code with the mds_session_timeout. With that, the client can at least determine when warnings might start showing up in the MDS' logs. Signed-off-by: Jeff Layton <jlayton@redhat.com> |
||
|---|---|---|
| .. | ||
| administration.rst | ||
| best-practices.rst | ||
| capabilities.rst | ||
| cephfs-journal-tool.rst | ||
| client-auth.rst | ||
| client-config-ref.rst | ||
| createfs.rst | ||
| dirfrags.rst | ||
| disaster-recovery.rst | ||
| eviction.rst | ||
| experimental-features.rst | ||
| file-layouts.rst | ||
| fstab.rst | ||
| full.rst | ||
| fuse.rst | ||
| hadoop.rst | ||
| health-messages.rst | ||
| index.rst | ||
| journaler.rst | ||
| kernel.rst | ||
| mantle.rst | ||
| mds-config-ref.rst | ||
| multimds.rst | ||
| posix.rst | ||
| quota.rst | ||
| standby.rst | ||
| troubleshooting.rst | ||
| upgrading.rst | ||