So we can generalize beyond NO* flags. We'll soon be adding other reasons
to not mark things up/down/in/out. This lets us keep all though checks in
one place.
The helper methods will tell us why we can't do the thing (e.g., "NODOWN
flag is set"). The callers will generally tell us exactly what didn't
happen (e.g., "failure report of X ignored").
Signed-off-by: Sage Weil <sage@newdream.net>
Do not mark down osds out when NOOUT flag is set. This is more or less
equivalent to setting a very long 'mon osd down out interval', but
reversible and less annoying.
Signed-off-by: Sage Weil <sage@newdream.net>
If the NOIN osdmap flag is set, do not mark booting osds in. Normally
we would for a range of reasons (always, new, auto-marked-out), but block
them all.
Do not limit manual 'ceph osd in N' commands.
Signed-off-by: Sage Weil <sage@newdream.net>
The down_pending_out tracks OSDs that are down that we may want to
auto-mark out. If an osd boots, it should be removed from this list
because it is no longer down; it doesn't matter whether it is marked in
or not.
Signed-off-by: Sage Weil <sage@newdream.net>
If the NODOWN osdmap flag is set,
- ignore osd failure reports
- do not mark osds down due to lack of osd/pg stats
We *do* still allow explicit admin 'ceph osd down N' commands, and a
booting OSD to mark the previous instance of itself down.
Signed-off-by: Sage Weil <sage@newdream.net>
If NOUP is set, do not send the boot message.
We already send onetime subscriptions to the osdmap, so we will find out
about osdmap flag changes. If it is cleared later, we'll pass into
start_boot() and _got_boot_version() again and send it then.
Signed-off-by: Sage Weil <sage@newdream.net>
Do not add an osd attempting to boot to the map if NOUP is sent. Instead,
send it the latest osdmap so it knows that it's not allowed to boot.
Signed-off-by: Sage Weil <sage@newdream.net>
In particular, the OSD may return EBUSY if there are still watchers.
Ignore ENOENT, as that may indicate we are cleaning up a previously
aborted removal.
Fixes: #2311
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
We clear out the osd entry when an osd goes up or down. Thus, if we find
it missing from an up osd, we should start the timer. Otherwise we get
behavior like this
2012-04-24 13:22:47.888291 7fa5bc587700 mon.peon5752@0(leader).osd e21633 OSDMonitor::handle_osd_timeouts: never got MOSDPGStat info from osd 521. Marking down!
2012-04-24 13:22:50.076394 7fa5bcd88700 log [INF] : osd.521 [2607:f298:4:2243::7088]:6806/53217 boot
2012-04-24 13:22:52.903558 7fa5bc587700 mon.peon5752@0(leader).osd e21638 OSDMonitor::handle_osd_timeouts: never got MOSDPGStat info from osd 521. Marking down!
2012-04-24 13:23:15.144532 7fa5bcd88700 log [INF] : osd.521 [2607:f298:4:2243::7088]:6806/53217 boot
2012-04-24 13:23:17.967118 7fa5bc587700 mon.peon5752@0(leader).osd e21663 OSDMonitor::handle_osd_timeouts: never got MOSDPGStat info from osd 521. Marking down!
2012-04-24 13:23:22.173778 7fa5bcd88700 log [INF] : osd.521 [2607:f298:4:2243::7088]:6806/53217 boot
2012-04-24 13:23:22.981556 7fa5bc587700 mon.peon5752@0(leader).osd e21668 OSDMonitor::handle_osd_timeouts: never got MOSDPGStat info from osd 521. Marking down!
2012-04-24 13:23:45.245380 7fa5bcd88700 log [INF] : osd.521 [2607:f298:4:2243::7088]:6806/53217 boot
when the pg stats message doesn't arrive quickly enough.
Fixes: #2341
Signed-off-by: Sage Weil <sage@newdream.net>
Reviewed-by: Greg Farnum <gregory.farnum@dreamhost.com>
The indices were set incorrectly when I whipped thi sup. That's what
you get for not testing nor being careful enough in review.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
Allow for '-h' and other options such as disabling the journal sync tests,
defining it is to be run on a btrfs FS, enabling exit on error (default is
now 'off'), and allow certain env variables to specify additional options
to each store.
Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
Make them unique by appending -<ptr>, so that the json we dump will remain
valid.
We may also want to allow people to share counters of the same type.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
The prt() varargs function generates this warning
test/rbd/fsx.c: In function ‘prt’:
warning: test/rbd/fsx.c:203:2: format not a string literal and no format arguments [-Wformat-security]
warning: test/rbd/fsx.c:205:3: format not a string literal and no format arguments [-Wformat-security]
Disable that check for the fsx build only.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
I was seeing failures of LibRBD.TestIOToSnapshot where we would fail to
refresh after rollback, even though the snap existed. I assume it is
because the std::string whose c_str() we were pointing to was reallocated.
Use a std::string here instead.
This code is weird.
Signed-off-by: Sage Weil <sage@newdream.net>
In collection_add we have a two-phase guard set on the linked object via
the old name. During replay, we might see that the dest name is missing
and replay the operation, and in the process overwrite a newer guard with
an older one.
Avoid this by checking the source name too, and skipping the operation
entirely if a new guard exists.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
Use FileStoreDiff instead of having the diff code embedded in the test,
allowing for more tests and people to use the code in case it comes in
hand.
Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
This code should be on a stand-alone class, instead of being embedded on
a single test, in case someone or something find it useful somewhere down
the line.
Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
The caller is still invalidating the entire cache, so we don't need to
deal with discard at this level. That might be worth cleaning up
later, though.
Fixes: #2296
Signed-off-by: Sage Weil <sage@newdream.net>
Do not assume the object extents are at the trailing edge of objects.
Instead, discard arbitrary extents. Fix callers.
Signed-off-by: Sage Weil <sage@newdream.net>
handle_sparse_read() was taking buf_ofs and buf_len, but buf_len was being
interpreted as the total size of the buffer, not the length of the extent
in the buffer start at buf_ofs. Both callers pass in an extent length, so
fix the zero code to do the right thing.
Specifically, the behavior I saw was:
- read range spanning 2 objects, trailing 20k and leading 50k
- first object didn't exist, zeroed first 20k of buffer
- second object didn't exist, zeroed next 30k (50k-20k) of buffer
- the last 20k of buffer was unzeroed.
Signed-off-by: Sage Weil <sage@newdream.net>
This makes it easier to interpret the dump, and makes it obvious what is
dump (and potentially a dup of something that was already logged) and what
is not.
Signed-off-by: Sage Weil <sage@newdream.net>
