user could manual compact OSD's omap as following:
1. ceph tell osd.id compact
2. ceph daemon osd.id compact
user's requests will be impacted during compaction.
Fixes: http://tracker.ceph.com/issues/19592
Signed-off-by: liuchang0812 <liuchang0812@gmail.com>
it matches the settings in vstart.sh, also it would be handy for those
who are still developing on btrfs, which is now marked as an experimental
features now.
Signed-off-by: Kefu Chai <kchai@redhat.com>
0 OSDs is not an error anymore in the new health checking implemented by
OSDMap::check_health(). this case was treated as an error before, see
OSDMonitor::get_health(). but an osdmap without any OSD is fine, i
think. but an osdmap with 3 OSDs, but all of them are down and out, this
is an error. and we do report this as an error. so, let's update the
test instead.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Add static service map registration for librgw/NFS. In this
verision registration is unconditional (e.g., unit tests would
register) and, in addition, since there is no API change, we
don't know anything about the upper-layer client.
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Pull in the latest releases from the past 5 months and fix some of the
links so they jump to the correct sections in the release notes.
Signed-off-by: Bryan Stillwell <bstillwell@godaddy.com>
The last_beacon map is local to an election interval; if there is a new
election completed we should reset it or else we may kill an apparently
laggy mgr that hasn't been able to get a beacon processed due to the mon
quorum changing, or had its beacon processed on a different leader.
Signed-off-by: Sage Weil <sage@redhat.com>
Cleaner prose for the auto-out case, and add
a cluster log message for OSDs that go out
at the behest of the administrator.
Signed-off-by: John Spray <john.spray@redhat.com>
This behaviour led to way too many messages going to
the cluster log when an OSD is marked in. Retain
the messages at debug level.
Signed-off-by: John Spray <john.spray@redhat.com>
Instead of a distinct health check for each possible
PG state, group the states into categories for availability,
degraded, damage, and report on that.
That way, while a PG/pool is suffering from one of those
bad PG states, health conditions don't keep toggling on and
off as we transition from one unavailable state to another
unavailable state.
Signed-off-by: John Spray <john.spray@redhat.com>
The PaxosService subclasses should be writing out
informative log messages, and not relying on
a stream of map summary prints to communicate
changes.
Signed-off-by: John Spray <john.spray@redhat.com>
Add a "Cluster is now healthy" to give clarity
after a series of "health check cleared" that
they were the last ones.
Convert certain health check messages into
well formed sentences.
Don't print severity in the log string (it's already
expressed in the severity of the log entry.
Signed-off-by: John Spray <john.spray@redhat.com>
Previously, the mgr would send MMonMgrReport indicating
a very unhappy PGMap to the mon right after startup.
This is a change to hold off on sending that report until
all the OSDs have reported in, or until some time has passed.
Signed-off-by: John Spray <john.spray@redhat.com>
The .available flag is there to tell MgrClients whether
to try and connect -- it isn't the right condition
for a health complaint.
Signed-off-by: John Spray <john.spray@redhat.com>
