Github shows up a `guidelines for contributing` while opening a new pull
request for any repository with a CONTRIBUTING file at the repo
root, which allows for a quick overview to contribute to the
repository.
Currently this file just links to the Submitting Patches and the
documentation start guide.
This workunit will be used by tests as a placeholder that always return
true. This is helpful in tests when a script from the qa/workunits
directory is mandatory but we do not care about testing anything. For
an example of how it can be used, check
https://github.com/ceph/ceph-qa-suite/pull/120
S3 API supports getting the location for a bucket, which gives out one
of those geographic zones (US-WEST-1, EU for eg). Also it returns an
empty string for the default region.
(http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETlocation.html)
Since LocationConstraint corresponds to regions in our case, this API
returns the region, for the "default" region empty string is returned
Adding basic unit test to test the new formatter class'
dump_format_ns. Since the functionality only affects XML (and other
implementations mimic dump_format exactly), tests are added for these.
`fmt.close_section()` is avoided in the tests as this calls an
assert (and there is no section to close) and this triggers a test
failure.
Since the base formatter was extended with a dump_format_ns class,
implementing this here. For now, this is exactly same as dump_format, as
the concept of ns in json is not used.
`dump_format_ns` is a generic formatter to dump a simple format along
with a namespace. It is `dump_format` with an optional ns. This also
extends the XML formatter with this functionality. This allows creation
of xml tags with ns and a specified format. The JSON Format doesn't
define a ns, and here the functionality is exactly same as that of
`dump_format`
Refactor ErasureCodeLrc::create_ruleset
1.Use CrushWrapper instead of crush C-api.
2.Make ruleset_id == rule_id, consist as the behavior in
CrushWrapper::add_simple_ruleset().
mds: clear objects' dirty flags after log segment is expired
When standby-replay MDS detects a log segment is expired, it should check
the expired segment's dirty lists and clear corresponding objects' dirty
bits. Otherwise these objects will be pinned in the standby-replay MDS's
cache forever.
John Spray [Mon, 1 Sep 2014 17:43:11 +0000 (18:43 +0100)]
mon: add MDS metric metadata to health detail
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.
John Spray [Wed, 27 Aug 2014 12:31:27 +0000 (13:31 +0100)]
mds: use HeartbeatMap to control beacons
...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.
Loic Dachary [Sun, 31 Aug 2014 17:14:55 +0000 (19:14 +0200)]
mailmap: add .peoplemap
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
Sage Weil [Sun, 31 Aug 2014 04:56:31 +0000 (21:56 -0700)]
common/LogEntry: fix warning on i386
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());
^
Sage Weil [Sat, 30 Aug 2014 02:27:34 +0000 (19:27 -0700)]
osd/ReplicatedPG: do not evict blocked objects
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>
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>
Loic Dachary [Wed, 27 Aug 2014 15:05:02 +0000 (17:05 +0200)]
erasure-code: ECRecPred must be true if all chunks can be recovered
ECRecPred assumes recovering any number of chunk is possible as long as
at least K chunks are available. It builds the want() set accordingly in
the constructor and arbitrarily set the first K chunks. But it would be
the same if it set the last K chunks.
While this is correct for jerasure and isa plugins, it is not true in
general. The predicate should assume that all chunks are going to be
recovered and return true if they can all be recovered. Otherwise, the
following can happen:
* a PG has chunks 0,1,2,3 for K=2, M=2
* ECRecPred is initialized a set want to 0,1 because K=2
* ECRecPred claims the plugin can recover when provided 0,1
* the plugin is then required to recover 0,1 using 2,3 and fails
This can happen for the LRC plugin with k=4,m=2,l=3 which is
Loic Dachary [Sun, 8 Jun 2014 15:25:41 +0000 (17:25 +0200)]
erasure-code: test LRC pool, profile and crush ruleset
Using the command line to create an LRC pool validates that the plugin
can be loaded and the ruleset created immediately after the crush table
is populated with the default rulesets.
Add a test that takes out the first OSD holding data for an object and
checks the recovery is effective by retrieving the object content and
checking it is as expected.
Loic Dachary [Fri, 15 Aug 2014 16:33:38 +0000 (18:33 +0200)]
erasure-code: high level LRC configuration
Add a configuration mode to the LRC plugin, suitable for most use cases
and simpler to explain and understand. It uses k,m parameters similar to
the jerasure and isa plugins and adds l for locality. For instance:
It is less flexible because k+m must be a multiple of l and other
similar relationships and also because it cannot express recursive
configurations with locality in the datacenter and locality in a rack
within the datacenter.
Loic Dachary [Sun, 8 Jun 2014 12:19:18 +0000 (14:19 +0200)]
erasure-code: locally repairable code plugin
Recursively apply erasure code techniques so that recovering from the
loss of some chunks only require a subset of the available chunks, most
of the time.
Loic Dachary [Sun, 24 Aug 2014 18:52:24 +0000 (20:52 +0200)]
erasure-code: delegate chunk remapping to the plugin
Remapping the chunks after they have been encoded by the plugin is fine
if remapping is transparent to the plugin. However, the goal is to
delegate the remapping of the chunks to the plugin, for LRC in
particular. The chunks are therefore reordered according to the
directions found in the mapping array before they are passed to
decode_chunks.
Loic Dachary [Sun, 24 Aug 2014 18:57:16 +0000 (20:57 +0200)]
erasure-code: override the default only if the plugin match
When setting a new erasure coded profile, the key/value of the default
profile are re-used so that ruleset-failure-domain=osd can be overridden
like so:
ceph osd erasure-code-profile set ruleset-failure-domain=osd
This is however not appropriate if the plugin is different from the
defaut plugin (for instance LRC instead of jerasure) because the
parameters are not the same.
If the plugin is changed, the default profile is not reused.
John Spray [Fri, 29 Aug 2014 17:34:39 +0000 (18:34 +0100)]
tools: use cout instead of cerr in journal tool
Aside from being a bit odd to begin with, using stderr
was causing tests to fail because the output was polluted
by log output which is also on stderr.
Fixes: 9281 Signed-off-by: John Spray <john.spray@redhat.com>
Sage Weil [Fri, 29 Aug 2014 15:29:35 +0000 (08:29 -0700)]
mds/RecoveryQueue: do not start prioritized items synchronously
When we prioritize an item move it into a second priority list/set, but
do not start immediately, so that we still obey the max. When we go to
start an item, pull items first off the priority list, then off the regular
list.
projects / ceph.git / log