The ceph-mon command usage is updated to document all of the ceph-mon
specific options.
The ceph tell usage examples for log and debug are using a deprecated syntax.
Signed-off-by: Loic Dachary <loic@dachary.org>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Based on a dialog with Sam ( as published at http://dachary.org/?p=2320 ).
* Remove PGBackend-h.rst because PGBackend.h is now in master.
* Fix typos caught by ispell
* Update recovery links to point to PGBackend recover methods
* Workaround formating warning
developer_notes.rst:3: WARNING: Duplicate explicit target name:
"erasurecodepluginexample" which should be legitimate.
Signed-off-by: Loic Dachary <loic@dachary.org>
* Update to the current state of the ghobject implementaiton and the fact
that they encode the shard_t Although the pool also contains the shard
id, it is less relevant to understand the implementation.
* Update with the erasure code plugin infrastructure and the example
plugin now in master.
* Move jerasure to a separate page to be expanded and link it from the
toc
* Kill the partial read and writes notes as it will probably not be
implemented in the near future. Kill some of the notes because they
are no longer relevant.
* Add a definition for "chunk rank"
* Reword, update schemas, fix typos.
Signed-off-by: Loic Dachary <loic@dachary.org>
Following the changes to when we set or increase the user_version, we
want to continue to return the best lower bound we can on the version
of any newly-created object. For ENOENT replies that means returning
info.last_user_version instead of the (potentially-zero) ctx->user_at_version.
Similarly, for cls_current_version we want to return the last version on
the PG rather than the last update to the object in order to provide
sensible version ordering across object deletes and creates.
Update the versions doc so it continues to be precise.
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Specify a user and pg_pool_t interface for tiering/caching specifications
Reviewed-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>
* unify conventions to match those used by jerasure ( data chunk = K,
coding chunk = M, use coding instead of parity, use erasures instead
of erased )
* make lines 80 characters long
* modify the descriptions to take into account that the chunk rank
will encoded in the pool name and not on a per object basis
* remove the doxygen link to ErasureCodeInterface because it fails
doc: asphyxiate does not support class
http://tracker.ceph.com/issues/6115
* only systematic codes are considered at this point ( all jerasure
techniques are systematic). Although the API could be extended to
include non systematic codes, it is probably a case of over
engineering at this point.
* add link to
http://tracker.ceph.com/issues/6113
add ceph osd pool create [name] [key=value]
* update the plugin system description to match the proposed
implementation http://tracker.ceph.com/issues/5877http://tracker.ceph.com/issues/4929 refs #4929
Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>
Signed-off-by: Loic Dachary <loic@dachary.org>
* replace the erasure code plugin abstract interface with a doxygen link
that will be populated when the header shows in master
* update the plugin documentation to reflect the current draft implementation
* fix broken link to PGBackend-h
* add a glossary to define chunk, stripe, shard and strip with a drawing
http://tracker.ceph.com/issues/4929 refs #4929
Signed-off-by: Loic Dachary <loic@dachary.org>
Explains how objects are stored and used in erasure coded pools. It is
the result of discussions that occured on the ceph-devel mailing list
around june 2013. The rationale behind each change can be found in the
archive of the mailing list. For instance, the coding of the chunk
number with the object or the decision to decode using any K chunks
instead of trying to fetch the data chunks when possible because it
would allow simple concatenation when systematic codes are used.
http://tracker.ceph.com/issues/4929 refs #4929
Signed-off-by: Loic Dachary <loic@dachary.org>
it is not easy to figure out what a PG temp is just by reading the
code although it is easy to understand with an example.
Signed-off-by: Loic Dachary <loic@dachary.org>
