test_librbd_fsx: use private RNG context

It is at the core of fsx to be able to reproduce the exact op sequence
that lead to a failure.  Use reentrant glibc RNG functions to make sure
that nothing else has to chance to mess up the sequence.

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
map-unmap.sh: drop the get_id() logic

Take advantage of the fact that 'rbd map' will now talk to udev and
output the device that got assigned by the kernel to the newly created
mapping.  Drop the get_id() cruft, udevadm settle and chown calls.

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
map-unmap.sh: fail if 'rbd rm' fails

Fail if 'rbd rm' fails - most probably it'd fail with "image still has
watchers" and in that case it's a bug in the kernel client which we do
want to notice.  Also nuke the trap-based error handling - cleanup() is
half-baked and not really necessary here.

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
[RGW, memory leaks] Memory leak in RGW initialization (Inserting new connection into connections map w/o check) has been fixed.

Memory leaks detector report:

$ valgrind  --leak-check=full /usr/bin/radosgw -c /etc/ceph/ceph.conf -n
client.radosgw.gateway -f
...
=16986== 1,262 (48 direct, 1,214 indirect) bytes in 1 blocks are definitely lost in loss record 81
of 83
==16986==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==16986==    by 0x618F0D: RGWRados::init_complete() (in /usr/bin/radosgw)
==16986==    by 0x618FE6: RGWRados::initialize() (in /usr/bin/radosgw)
==16986==    by 0x63BB23: RGWRados::initialize(CephContext*, bool) (in /usr/bin/radosgw)
==16986==    by 0x634D20: RGWStoreManager::init_storage_provider(CephContext*, bool) (in
/usr/bin/radosgw)
==16986==    by 0x5B8970: RGWStoreManager::get_storage(CephContext*, bool) (in /usr/bin/radosgw)
==16986==    by 0x5B6D5D: main (in /usr/bin/radosgw)
...

Signed-off-by: Andrey Kuznetsov <Andrey_Kuznetsov@epam.com>
[RGW, memory leak] Memory leak in RGW GC (losing pointer during allocating Ceph-context) has been fixed.

Memory leaks detector report:
...
==117947== 11,725 (200 direct, 11,525 indirect) bytes in 25 blocks are definitely lost in loss
record 82 of 82
==117947==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==117947==    by 0x687CC1: RGWGC::process(int, int) (in /usr/bin/radosgw)
==117947==    by 0x6884D1: RGWGC::process() (in /usr/bin/radosgw)
==117947==    by 0x68875C: RGWGC::GCWorker::entry() (in /usr/bin/radosgw)
==117947==    by 0x55F890A: Thread::_entry_func(void*) (in /usr/lib64/librados.so.2.0.0)
==117947==    by 0x34D46079D0: start_thread (in /lib64/libpthread-2.12.so)
==117947==    by 0x34D42E8B6C: clone (in /lib64/libc-2.12.so)
...

Signed-off-by: Andrey Kuznetsov <Andrey_Kuznetsov@epam.com>
[RGW, memory leak] Memory leak in RGW has been fixed: deletion of allocated pointer to pointer to Log object has been added to "on_exit" handler.

Memory leaks detector report:

$ valgrind  --leak-check=full /usr/bin/radosgw -c /etc/ceph/ceph.conf -n
client.radosgw.gateway -
...
==16986== 8 bytes in 1 blocks are definitely lost in loss record 14 of 83
==16986==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==16986==    by 0x58980B8: ceph::log::Log::set_flush_on_exit() (in /usr/lib64/librados.so.2.0.0)
==16986==    by 0x6BE3CA: global_init(std::vector<char const*, std::allocator<char const*> >*, st
==16986==    by 0x5B6B0A: main (in /usr/bin/radosgw)
...

Signed-off-by: Andrey Kuznetsov <Andrey_Kuznetsov@epam.com>
krbd: rework the unmap retry loop

The retry loop in the unmap path turned out to be insufficient for
doing long fsx -K runs.  Replace it with a single retry and then call
out to 'udevadm settle' if the retry doesn't help.

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
doc: RPM instructions correction

Signed-off-by: John Spray <john.spray@inktank.com>
mds: add 'enabled' flag to MDSMap

When 'enabled' is false, the MDSMap is effectively
null.  This allows Ceph clusters with no filesystem
or filesystem data/metadata pools.

Signed-off-by: John Spray <john.spray@inktank.com>
mds: no initial filesystem

Because not everyone uses CephFS, we would
like to avoid initially creating any data/metadata
pools for CephFS.

To avoid creating those pools, we must avoid initially
populating the MDSMap.

Signed-off-by: John Spray <john.spray@inktank.com>
osdmap: Don't create FS pools by default

Because many Ceph users don't use the filesystem,
don't create the 'data' and 'metadata' pools by
default -- they will be created by newfs if
they are needed.

Signed-off-by: John Spray <john.spray@inktank.com>
mon: don't require 'sure' flag for new fs

Only prompt for --yes-i-really-mean-it if there
is an existing FS.

Signed-off-by: John Spray <john.spray@inktank.com>
mon: warn in newfs if crash_replay_interval=0

This is the setting we would apply to data pools
created automatically, so notify the user if they're
failing to use it for data pools they have created
by hand.

Signed-off-by: John Spray <john.spray@inktank.com>
mon: enable deleting pools when FS disabled

Signed-off-by: John Spray <john.spray@inktank.com>
mon: stop MDSMonitor when FS disabled

Where 'stopped' means ignoring beacons and
not performing 'tick' activities.

Signed-off-by: John Spray <john.spray@inktank.com>
mon: hide mdsmap in 'ceph status' if not enabled

Previously we checked if the MDS map had ever been
updated (epoch > 1), now we have an explicit flag
for whether it's enabled.

Signed-off-by: John Spray <john.spray@inktank.com>
erasure-code: add definitions to the glossary

and fix a typo

Signed-off-by: Loic Dachary <loic@dachary.org>
mon: add `ceph fs [new|rm|ls]`

Signed-off-by: John Spray <john.spray@inktank.com>
vstart: update for newfs/rmfs changes

Signed-off-by: John Spray <john.spray@inktank.com>
test/qa: update for MDSMonitor changes

Accomodate changes:
 * data and metadata pools no longer exist by default
 * filesystem-using tests must use `fs new` to create
   the filesystem first.

Signed-off-by: John Spray <john.spray@inktank.com>