Previously tried to read entire journal
into memory in one go, which was problematic
for large journals.
Fixes: #11746
Signed-off-by: John Spray <john.spray@redhat.com>
so the peon can remove the ignored mdsbeacon request from the
routed_requets at seeing this reply, and hence no longer resend the
request.
Fixes: #11590
Signed-off-by: Kefu Chai <kchai@redhat.com>
While we're at it, take only /usr/lib instead of all of /usr
to keep the overall file count more modest.
Fixes: #11807
Signed-off-by: John Spray <john.spray@redhat.com>
fix "pg ls" with states of "recovering" and/or "repair"
Reviewed-by: Joao Eduardo Luis <joao@suse.de>
Reviewed-by: Greg Farnum <gfarnum@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Setting this option to false reverts librbd to legacy behavior
where AIO operations could potentially block.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Use same_interval_since set to zero to communicate that an import has happened
and the correct value needs to be computed.
Fixes: #10794
Signed-off-by: David Zafman <dzafman@redhat.com>
The profile stored by the plugin may be different from the one set by
the user: it includes defaults. When the plugin is initialized, the
profile is modified to include the default values. Verify that the
modified profile matches what the get_profile() method returns, to guard
against inconsistencies from the erasure code plugin implementation.
http://tracker.ceph.com/issues/11663Fixes: #11663
Signed-off-by: Loic Dachary <ldachary@redhat.com>
An erasure-code profile set by the user may be modified by the erasure
code plugin, most of the time to add default values for domain failure,
techniques etc.
Whenever the monitor gets an erasure code profile from the user or the
configuration file, it uses it to initialize the corresponding erasure
code plugin and:
* validate the profile and get an error if it is invalid
* get a normalized profile
The normalized profile is stored in the OSDMap. Should the user try
to set the same erasure code profile with the different values that lead
to the same normalized form, the modification will be accepted as a
noop, as if the same values were given. For instance:
ceph osd erasure-code-profile set myprofile k=2
ceph osd erasure-code-profile set myprofile k=2 m=1
are the same because the default value for m is 1 for the default
jerasure plugin.
If the normalized form is not used for storage and comparison, the
second call with m=1 will fail and require --force to override
myprofile, although the user can read from the documentation that it
matches the default value.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The ErasureCode::init function is implemented to store the profile and
is called by the init method of each plugin. The
ErasureCode::get_profile function is implemented to return the profile
that was stored. A specialized ostream<< function is implemented to
facilitate the display of the profile.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Add the get_profile method to the interface and make it a pure virtual.
Each plugin is expected to return the profile currently in use. Although
the profile is also stored in the OSDMap, it provides a convenient
introspection method to validate that the profile being set is indeed
the profile being used.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
RPM spec files summary should not end with a dot.
This was inconsistent across the ceph rpm packages
and creates errors with rpm lint.
Signed-off-by: Owen Synge <osynge@suse.com>
1. Creating a filesystem using a
readonly tier on an EC pool (should be forbidden)
2. Removing a tier from a replicated base pool (should
be permitted)
Signed-off-by: John Spray <john.spray@redhat.com>
For EC pools, we need a tier that is not just forwarding
writes, in order to provide the ops required
by CephFS.
Signed-off-by: John Spray <john.spray@redhat.com>
