osd dump is like this:
pool 0 'data' rep size 2 crush_ruleset 0 object_hash rjenkins pg_num
768 pgp_num 768 lpg_num 2 lpgp_num 2 last_change 1 owner 0
crash_replay_interval 45
pool 1 'metadata' rep size 2 crush_ruleset 1 object_hash rjenkins
pg_num 768 pgp_num 768 lpg_num 2 lpgp_num 2 last_change
after upgrade to v0.45 stack trace is as follows:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffeac55700 (LWP 11011)]
0x75ebb445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x75ebb445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00
Am 24. April 2012 18:26 schrieb Sage Weil :
> On Tue, 24 Apr 2012, Josef Bacik wrote:
>> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote:
>> > After running ceph on XFS for some time, I decided to try btrfs again.
>> > Performance with the current "for-linux-min" branch and big me
On 04/25/2012 12:28 PM, Christian Brunner wrote:
> I've tried test_filestore_workloadgen, but it didn't work very well.
> After 5 Minutes it terminated with the following messages:
>
> 2012-04-25 11:28:57.768709 7fcac3f69760 0 Destroying collection
> '0.1_head' (358 objects)
> 2012-04-25 11:29:07
After removing pool snapshot I was trying to make self managed
snapshot and after reading source this was the root cause of this
problem.
On Wed, Apr 25, 2012 at 1:24 PM, Tomasz Paszkowski wrote:
> after upgrade to v0.45 stack trace is as follows:
>
> Program received signal SIGABRT, Aborted.
>
Hi,
I've been experimenting with failure scenarios to make sure
I understand what happens when an OSD drops out. In particular,
I've been using "ceph osd out " and watching my all my OSD
servers to see where the data from the removed OSD ends up
after recovery. I've been doing this testing with
