Simulate the cases where the activation (via udev running trigger)
sequences are:
* journal then lockbox
* data then lockbox
* lockbox
All of them must end with the OSD verfied to be up.
Signed-off-by: Loic Dachary <loic@dachary.org>
The ceph-disk activate errors were ignored and not displayed. Capture
stdout/stderr and display it if the exit code is non zero. Also fail
when an activate fails.
Pass the --verbose flag to activate, if given to trigger.
Signed-off-by: Loic Dachary <loic@dachary.org>
list may try to mount partitions to figure out the OSD id and other
details. If it does so while the OSD is activated, it will race and lead
to errors, either for activation or for list.
Signed-off-by: Loic Dachary <loic@dachary.org>
The ceph-disk page is often obsolete, mostly because maintaining
it requires a significant amount of copy/paste and re-formatting.
Now that the --help of ceph-disk has been updated to include a more
verbose explanation of each subcommand, simplify the man page to
give an overview of the subcommands and suggest the --help is used
to get more information.
Signed-off-by: Loic Dachary <loic@dachary.org>
Instead of storing the dmcrypt keys in the /etc/ceph/dmcrypt-keys
directory, they are stored in the monitor. If a machine with
OSDs created with ceph-disk prepare --dmcrypt is lost, it does
not contain the key that would allow to decrypt their content.
The dmcrypt key is retrieved from the monitor using a different keyring
for each OSD. It is stored in a small partition called the lockbox. At
boot time the lockbox is mounted
/var/lib/ceph/osd-lockbox/$uuid
and used when the $uuid partition is detected by udev to map it with
cryptsetup.
The OSDs that were prepared prior to the lockbox implementation are
supported by looking up the key found in /etc/ceph/dmcrypt-keys before
looking in /var/lib/ceph/osd-lockbox/$uuid.
http://tracker.ceph.com/issues/14669Fixes: #14669
Signed-off-by: Loic Dachary <loic@dachary.org>
The ceph-disk trigger deals with dmcrypt mapping which is redundant with
what ceph-disk activate-* does when the --dmcrypt flag is set. Remove
the dmcrypt mapping code and add the --dmcrypt flag to ceph-disk
activate-* where relevant.
Signed-off-by: Loic Dachary <loic@dachary.org>
The dmcrypt boolean needs to be set for destroy to ensure the
journal/block partitions are 'cryptsetup remove'.
Signed-off-by: Loic Dachary <loic@dachary.org>
rgw: indexless buckets (Yehuda Sadeh)
- can define a policy, for which buckets are indexless
- users can then create buckets under the specified placement target
- indexless buckets will not be synced across zones
- does not work with (s3) versioned buckets
Reviewed-by: Matt Benjamin <mbenjamin@redhat.com>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
When run without "--no-verify", all verification errors are noted,
but they are not forwarded/reported anywhere else but to cerr, which
will cause automated testing to ignore them. Make seq_read_bench and
rand_read_bench return -EIO on any verification error which will,
in turn, return it back to caller.
Fixes: #14971
Signed-off-by: Piotr Dałek <piotr.dalek@ts.fujitsu.com>
"Pool <pool> has too few pgs" is okay assuming it does not take other
pools into account. And since it does, it is confusing in the following
scenario:
1. Create two pools, one with small pg count and one with large
pg count
2. Put a whole lot of objects in smaller pool, resulting in "too few
pgs" warning on that pool, which is expected behavior.
3. Put a whole lot of objects in larger pool, warning goes away.
Suddenly smaller pool has plenty of PGs?
Current message suggests adding more nodes (or PGs) to pool, when
actually it's warning about significantly more objects in that
particular pool than in the other pools.
Signed-off-by: Piotr Dałek <piotr.dalek@ts.fujitsu.com>
Suppose: bluestore_overlay_max_length=bluestore_min_alloc_size;
bluestore_overlay_max = 2;
For the following ops:
write(off=0, len=4096) --->write into overlay
write(off=4096, len=4096)-->write into overlay
write(off=0, len=bluestore_min_alloc_size)-->because overlay_map.size()
>=2, it allocate a extent.
It should trim overlay data(0,4096) &(4096, 4096),and then write(0,
bluestore_min_alloc_size).
But the original code don't trim overlay data.
This make the later read data is orignal data rather that new data.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
Suppose: bluestore_overlay_max_length == bluestore_min_alloc_size
The orignal code which calc content of written whether locate in a
extent:
(offset / min_alloc_size) == (offset + length) /min_alloc_size
This will make the case which offset=0 & length =min_alloc_size locate
in the different extent.
In fact, this content is in the same extent.
Change end = offset + length - 1 make work.
Fixes: #14954
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
When clean_up_slow() fails, it returns "-5" which is equal to -EIO.
Change it in source, so it's not confusing for someone who does not
remember all error codes (functionality remains the same).
Signed-off-by: Piotr Dałek <piotr.dalek@ts.fujitsu.com>
The heap_profiler object library only needs to be
added to mon,mds, and osd instead of the numerous
targets it is part of
Signed-off-by: Ali Maredia <amaredia@redhat.com>
