This is a bit wonky because the mon health structure expects
a string, and we have a key-val structure, but it's better
to output this somehow than to have it rot as a purely internal
thing.
Signed-off-by: John Spray <john.spray@redhat.com>
...so that if something hogs mds_lock without
pinging the heartbeat map, we will stop sending
beacons to the mon and it will have the chance
to recognise that we are laggy.
Signed-off-by: John Spray <john.spray@redhat.com>
This allows it to handle its own MSG_MDS_BEACON
messages from the mon, outside of mds_lock.
This is less important than the sending of beacons
being outside the lock, but still nice to have and
gets all the beacon messaging in one place.
Signed-off-by: John Spray <john.spray@redhat.com>
CID 1204294 (#1 of 1): Resource leak (RESOURCE_LEAK)
leaked_storage: Variable filter going out of scope leaks the
storage it points to.
Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
We hit the 1000 lock limit on
ubuntu@teuthology:/a/teuthology-2014-08-31_02:30:01-rados-next-testing-basic-multi/463411
Fixes: #9309
Signed-off-by: Sage Weil <sage@redhat.com>
Add tests to fail as soon as an unexpected condition is met in
test_mon_osd. Otherwise the actual error will be more difficult find in
the logs.
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
In .mailmap, an individual may be represented by multiple mails which
may reflect an organization affiliation change that needs to be
preserved to find out which organization sponsored which commit.
The .peoplemap file aggregates these mails to show a single line for
each person
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
common/LogEntry.cc: In member function 'void LogEntry::log_to_syslog(std::string, std::string)':
warning: common/LogEntry.cc:161:20: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
msg.c_str());
^
Signed-off-by: Sage Weil <sage@redhat.com>
If the object is blocked, that means we are either still promoting it, or
we are in the process of doing a blocking flush. In both cases, do not
evict it just yet. For the promotion case in particular this can cause a
very long op delay because we'll have to restart the promotion, and this
can potentially loop indefinitely.
For the flush case, flushes are generally only blocking when the user
explicitly requests it. In that case, we are not particularly concerned
that we may delay the objects eventual eviction as the user is probably
controlling that anyway (and even if they aren't, the agent will still
try this object again later).
Fixes: #9285
Reported-by: Wang, Zhiqiang <zhiqiang.wang@intel.com>
Signed-off-by: Sage Weil <sage@redhat.com>
The preceding loop could terminate with p == snapset.clones.end(), which
we assign to dnewest. We can't dereference the iterator in that case.
For example:
start_flush ffe627f3/foo/a/test-rados-api-plana05-22080-18/83 v430'42 uv130 blocking
snapset b=[b,a]:[a,b]+head
start_flush no older clones
prev_snapc will be 0, oi.snaps will be [a], p will end up at end(), get
assigned to dnewest, and we'll dereference. It's only sometime harmful
though because we may still take the right (else) branch...
Fixes: #9294
Signed-off-by: Sage Weil <sage@redhat.com>
