Re: Replacing a failed disk/OSD: unfound object

Thanks Tommi. I rebuilt the ceph cluster a few times just to reproduce the situation. The result seems mixed, more likely btrfs failed (after power reset). But it does happen anyway. The big question is: However rare, unfound object situation makes the *entire* ceph file system not

Re: problem of operation rm -rf

hi.Tommi here is my mds.0.log 2011-07-12 09:09:53.014498 b6228b90 -- 192.168.1.103:6800/3075 == client4099 192.168.1.103:0/2582678147 41 client_session(request_renewcaps seq 2) 28+0+0 (3171197051 0 0) 0x982cdd0 con 0x986 2011-07-12 09:09:53.014579 b6228b90 -- 192.168.1.103:6800/3075

Re: Delayed inode operations not doing the right thing with enospc

2011/6/7 Josef Bacik jo...@redhat.com: On 06/06/2011 09:39 PM, Miao Xie wrote: On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote: I got a lot of these when running stress.sh on my test box This is because use_block_rsv() is having to do a reserve_metadata_bytes(), which shouldn't

Re: Replacing a failed disk/OSD: unfound object

On Tue, 12 Jul 2011, Meng Zhao wrote: Thanks Tommi. I rebuilt the ceph cluster a few times just to reproduce the situation. The result seems mixed, more likely btrfs failed (after power reset). But it does happen anyway. The big question is: However rare, unfound object situation makes the

[PATCH] crushtool: Add call to global_init() to avoid dout segfault

Signed-off-by: Jim Schutt jasc...@sandia.gov --- src/crushtool.cc |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/crushtool.cc b/src/crushtool.cc index f2a35f9..336d456 100644 --- a/src/crushtool.cc +++ b/src/crushtool.cc @@ -845,6 +845,10 @@ int main(int argc,