Flattening reads the logical child object from the parent image, and
then does a copyup operation if the data is non-zero. This is
equivalent to doing a zero-length write to each object in the
child image. Do this instead, so that we can easily control how
many are in flight, and eliminate some code as well.
Since we no longer read from the parent within the flatten function,
the buffer is not needed. It would be leaked in some error conditions,
but since's it's unecessary we can just get rid of it.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
If the parent image is logically zero for the range of a child object,
it's equivalent to the object not existing. Save some I/O and network
bandwidth and don't send the useless zeroes.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Speed up deletions when resizing down or removing an image by keeping
up 10 operations in flight by default.
Refs: #2256
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
This is convenient to use to turn synchronous calls into asynchronous
calls with a limited number of operations in flight concurrently.
It assumes the caller will wait for all operations to complete at the
end.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Add installed, but not packaged files to ceph-test (ceph-monstore-tool,
ceph-osdomap-tool) rpm file section.
Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
This is what the upstart ceph-osd.conf does; we need to do the same so that
new OSDs (e.g., that ceph-deploy creates) get added to the crush map.
Signed-off-by: Sage Weil <sage@inktank.com>
leveldb has static state that prevents it from recreating its worker thread
after our fork(), even when we close and reopen the database (tsk tsk!).
Avoid this by forking early, before we touch leveldb.
Hide the details in a Preforker class. This is modeled after what
ceph-fuse already does; we should convert it later.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
We need to go map-by-map to get the parents right in consume_map()
just as we must in load_pgs().
Fixes: 4884
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
"complete list of distributions" should be complete list of releases since we already know what distributions are supported and the list specifies releases. (Wheezy, Precise etc.)
In load_pgs(), we previously called assigned children starting
at the loaded pg created between its stored epoch and the current
osdmap to have that pg as their parent. This is not correct, some
of the children may have been split in subsequent epochs from children
split in earlier epochs. Instead, do each map individually.
Signed-off-by: Samuel Just <sam.just@inktank.com>
expand_pg_num() and load_pgs() may result in a pg with children
in pending_splits which also have children in pending_splits (etc).
Signed-off-by: Samuel Just <sam.just@inktank.com>
