common: seq_read_bench argument order changed
The argument order for seq_read_bench in src/common/obj_bencher.h has
been changed to match the argument order in obj_bencher.cc

Calls to seq_read_bench already use the correct order.
seq_read_bench also matches the order of rand_read_bench and
write_bench

Signed-off-by: Kevin Dalley <kevin@kelphead.org>
remove ceph restarts on upgrades for RPMs

Signed-off-by: Alfredo Deza <alfredo.deza@inktank.com>
remove suse service restarts

Signed-off-by: Alfredo Deza <alfredo.deza@inktank.com>
Merge pull request #2109 from ceph/wip-8849

remove ceph restarts on upgrades for RPMs

Backport: firefly
Reviewed-by: Sage Weil <sage@redhat.com>
logrotate.conf: fix osd log rotation under upstart

In commit 7411c3c6a42bef5987bdd76b1812b01686303502 we generalized this
enumeration code by copying what was in the upstart scripts.  However,
while the mon and mds directories get a 'done' file, the OSDs get a 'ready'
file.  Bah!  Trigger off of either one.

Backport: firefly
Signed-off-by: Sage Weil <sage@redhat.com>
Merge pull request #2116 from ceph/wip-logrotate

logrotate.conf: fix osd log rotation

Reviewed-by: Dan Mick <dan.mick@inktank.com>
rgw: fix decoding + characters in URL

Fixes: #8702
Backport: firefly

Only decode + characters to spaces if we're in a query argument. The +
query argument.  The + => ' ' translation is not correct for
file/directory names.

Resolves http://tracker.ceph.com/issues/8702

Reviewed-by: Yehuda Sadeh <yehuda@redhat.com>
Signed-off-by: Brian Rak <dn@devicenull.org>
osd: init local_connection for fast_dispatch in _send_boot()

We were not properly setting up Sessions on the local_connection for
fast_dispatch'ed Messages if the cluster_addr was set explicitly: the OSD
was not in the dispatch list at bind() time (in ceph_osd.cc), and nothing
called it later on. This issue was missed in testing because Inktank only
uses unified NICs.

That led to errors like the following:

When do ec-read, i met a bug which was occured 100%. The messages are:
2014-07-14 10:03:07.318681 7f7654f6e700 -1 osd/OSD.cc: In function
'virtual void OSD::ms_fast_dispatch(Message*)' thread 7f7654f6e700 time
2014-07-14 10:03:07.316782 osd/OSD.cc: 5019: FAILED assert(session)

 ceph version 0.82-585-g79f3f67 (79f3f6749122ce2944baa70541949d7ca75525e6)
 1: (OSD::ms_fast_dispatch(Message*)+0x286) [0x6544b6]
 2: (DispatchQueue::fast_dispatch(Message*)+0x56) [0xb059d6]
 3: (DispatchQueue::run_local_delivery()+0x6b) [0xb08e0b]
 4: (DispatchQueue::LocalDeliveryThread::entry()+0xd) [0xa4a5fd]
 5: (()+0x8182) [0x7f7665670182]
 6: (clone()+0x6d) [0x7f7663a1130d]
 NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.

To resolve this, we have the OSD invoke ms_handle_fast_connect() explicitly
in send_boot(). It's not really an appropriate location, but we're already
doing a bunch of messenger twiddling there, so it's acceptable for now.

Signed-off-by: Ma Jianpeng <jianpeng.ma@intel.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
(cherry picked from commit 9061988ec7eaa922e2b303d9eece86e7c8ee0fa1)
osd: allow greedy get_write() for ObjectContext locks

There are several lockers that need to take a write lock
because there is an operation that is already in progress and
know it is safe to do so.  In particular, they need to skip
the starvation checks (op waiters, backfill waiting).

Signed-off-by: Sage Weil <sage@redhat.com>
osd/ReplicatedPG: greedily take write_lock for copyfrom finish, snapdir

In the cases where we are taking a write lock and are careful
enough that we know we should succeed (i.e, we assert(got)),
use the get_write_greedy() variant that skips the checks for
waiters (be they ops or backfill) that are normally necessary
to avoid starvation.  We don't care about staration here
because our op is already in-progress and can't easily be
aborted, and new ops won't start because they do make those
checks.

Fixes: #8889
Signed-off-by: Sage Weil <sage@redhat.com>
osd/ReplicatedPG: debug obc locks

Signed-off-by: Sage Weil <sage@redhat.com>
common/random_cache: fix typo

Signed-off-by: Sage Weil <sage@redhat.com>
ceph.spec.in: split out ceph-common as in Debian

Move files, postun scriptlet, and add dependencies on ceph-common
where appropriate

Signed-off-by: Sandon Van Ness <sandon@inktank.com>
(cherry picked from commit e131b9d5a5e90e87d8a8346cb96cb5a26135c144)
ceph.spec.in: whitespace fixes

Signed-off-by: Sandon Van Ness <sandon@inktank.com>
(cherry picked from commit ec8af52a5ede78511423a1455a496d46d580c644)
Fix/add missing dependencies:

- rbd-fuse depends on librados2/librbd1
- ceph-devel depends on specific releases of libs and libcephfs_jni1
- librbd1 depends on librados2
- python-ceph does not depend on libcephfs1

Signed-off-by: Sandon Van Ness <sandon@inktank.com>
(cherry picked from commit 7cf81322391b629b241da90181800ca1f138ce78)
ceph.spec.in: rhel7-related changes:

udev rules: /lib -> /usr/lib
/sbin binaries move to /usr/sbin or %{_sbindir}

Signed-off-by: Sandon Van Ness <sandon@inktank.com>
(cherry picked from commit 235e4c7de8f8efe491edefbdde8e5da4dfc44034)
ceph.spec.in: add bash completion file for radosgw-admin

Signed-off-by: Sandon Van Ness <sandon@inktank.com>
(cherry picked from commit b70096307130bcbac176704493a63c5d039d3edc)
store_test: add long name collection_move_rename tests

Currently fails.

Signed-off-by: Samuel Just <sam.just@inktank.com>
ceph_test_objectstore: fix warning

Signed-off-by: Sage Weil <sage@redhat.com>
os/LFNIndex: handle long object names with multiple links (i.e., rename)

When we rename an object (collection_move_rename) to a different name, and
the name is long, we run into problems because the lfn xattr can only track
a single long name linking to the inode.  For example, suppose we have

foobar -> foo_123_0 (attr: foobar) where foobar hashes to 123.

At first, collection_add could only link a file to another file in a
different collection with the same name. Allowing collection_move_rename
to rename the file, however, means that we have to convert:

col1/foobar -> foo_123_0 (attr: foobar)

to

col1/foobaz -> foo_234_0 (attr: foobaz)

This is a problem because if we link, reset xattr, unlink we end up with

col1/foobar -> foo_123_0 (attr: foobaz)

if we restart after we reset the attr.  This will cause the initial foobar
lookup to since the attr doesn't match, and the file won't be able to be
looked up.

Fix this by allow *two* (long) names to link to the same inode.  If we
lfn_link a second (different) name, move the previous name to the "alt"
xattr and set the new name.  (This works because link is always followed
by unlink.)  On lookup, check either xattr.

Don't even bother to remove the alt xattr on unlink.  This works as long
as the old name and new name don't hash to the same shortname and end up
in the same LFN chain.  (Don't worry, we'll fix that next.)

Fixes part of #8701
Signed-off-by: Sage Weil <sage@redhat.com>