ceph.spec.in:  Fedora builds debuginfo by default.

Signed-off-by: Gary Lowell <gary.lowell@inktank.com>
leveldb:  Update submodule

Signed-off-by: Gary Lowell <gary.lowell@inktank.com>
autogen.sh:  Create m4 directory for leveldb

Signed-off-by: Gary Lowell <gary.lowell@inktank.com>
.gitignore:  Add ar-lib to ignore list
log: fix flush/signal race

We need to signal the cond in the same interval where we hold the lock
*and* modify the queue.  Otherwise, we can have a race like:

 queue has 1 item, max is 1.
 A: enter submit_entry, signal cond, wait on condition
 B: enter submit_entry, signal cond, wait on condition
 C: flush wakes up, flushes 1 previous item
 A: retakes lock, enqueues something, exits
 B: retakes lock, condition fails, waits
  -> C is never woken up as there are 2 items waiting

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
(cherry picked from commit 50914e7a429acddb981bc3344f51a793280704e6)
log: fix log_max_recent config

<facepalm>

Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit 4de7748b72d4f90eb1197a70015c199c15203354)
log: 10,000 recent log entries

This is what we were (wrongly) doing before, so there are no memory
utilization surprises.

Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit 78286b1403a5e0f14f95fe6b92f2fdb163e909f1)
init-ceph: use SSH in "service ceph status -a" to get version

When running "service ceph status -a", a version number was never
returned for remote hosts, only for the local.  This was because
the command to query the version number didn't use the do_cmd
function, which is responsible for running the command over SSH
when needed.

Modify the ceph init.d script to use do_cmd for querying the
Ceph version.

Signed-off-by: Travis Rhoden <trhoden@gmail.com>
(cherry picked from commit 60fdb6fda6233b01dae4ed8a34427d5960840b84)
init-ceph: fix status version check across machines

The local state isn't propagated into the backtick shell, resulting in
'unknown' for all remote daemons.  Avoid backticks altogether.

Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit 6c7b667badc5e7608b69c533a119a2afc062e257)
log: fix locking typo/stupid for dump_recent()

We weren't locking m_flush_mutex properly, which in turn was leading to
racing threads calling dump_recent() and garbling the crash dump output.

Backport: bobtail, argonaut
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
(cherry picked from commit 43cba617aa0247d714632bddf31b9271ef3a1b50)
log: broadcast cond signals

We were using a single cond, and only signalling one waiter.  That means
that if the flusher and several logging threads are waiting, and we hit
a limit, we the logger could signal another logger instead of the flusher,
and we could deadlock.

Similarly, if the flusher empties the queue, it might signal only a single
logger, and that logger could re-signal the flusher, and the other logger
could wait forever.

Intead, break the single cond into two: one for loggers, and one for the
flusher.  Always signal the (one) flusher, and always broadcast to all
loggers.

Backport: bobtail, argonaut
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
(cherry picked from commit 813787af3dbb99e42f481af670c4bb0e254e4432)
os/FileStore: fix non-btrfs op_seq commit order

The op_seq file is the starting point for journal replay.  For stable btrfs
commit mode, which is using a snapshot as a reference, we should write this
file before we take the snap.  We normally ignore current/ contents anyway.

On non-btrfs file systems, however, we should only write this file *after*
we do a full sync, and we should then fsync(2) it before we continue
(and potentially trim anything from the journal).

This fixes a serious bug that could cause data loss and corruption after
a power loss event.  For a 'kill -9' or crash, however, there was little
risk, since the writes were still captured by the host's cache.

Fixes: #3721
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
(cherry picked from commit 28d59d374b28629a230d36b93e60a8474c902aa5)
config: change default log_max_recent to 10,000

Commit c34e38bcdc0460219d19b21ca7a0554adf7f7f84 meant to do this but got
the wrong number of zeros.

Signed-off-by: Sage Weil <sage@inktank.com>
ObjectCacher: fix off-by-one error in split

This error left a completion that should have been attached
to the right BufferHead on the left BufferHead, which would
result in the completion never being called unless the buffers
were merged before it's original read completed. This would cause
a hang in any higher level waiting for a read to complete.

The existing loop went backwards (using a forward iterator),
but stopped when the iterator reached the beginning of the map,
or when a waiter belonged to the left BufferHead.

If the first list of waiters should have been moved to the right
BufferHead, it was skipped because at that point the iterator
was at the beginning of the map, which was the main condition
of the loop.

Restructure the waiters-moving loop to go forward in the map instead,
so it's harder to make an off-by-one error.

Possibly-fixes: #3286
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
(cherry picked from commit 2e862f4d183d8b57b43b0777737886f18f68bf00)
ReplicatedPG: requeue waiting_for_ondisk in apply_and_flush_repops

Fixes: #3722
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
osd: fix race in do_recovery()

Verify that the PG is still RECOVERING or BACKFILL when we take the pg
lock in the recovery thread.  This prevents a crash from an invalid
state machine event when the recovery queue races with a PG state change
(e.g., due to peering).

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
v0.48.3argonaut