When accessing multiple RBD-Volumes from one VM in parallel, we are
receiving an assertion:
./osd/OSDMap.h: In function 'entity_inst_t OSDMap::get_inst(int)':
./osd/OSDMap.h:460: FAILED assert(exists(osd) && is_up(osd))
ceph version 0.22.1 (commit:c6f403a6f441184956e00659ce713eaee7014279)
1: (Obje
Here is another problem (I think it's unrelated to the previous, but
I'm not sure).
One of our osds crashed with the following message:
osd/ReplicatedPG.cc: In function 'void ReplicatedPG::sub_op_modify(MOSDSubOp*)':
osd/ReplicatedPG.cc:2403: FAILED assert(!missing.is_missing(soid))
ceph version
Do you have any down OSDs? Looking through the code I am noticing an
issue with down OSDs where op_submit can get an error code that it
isn't watching for, but there may be checks in other places to prevent
that actually happening.
-Greg
On Tue, Oct 26, 2010 at 5:13 AM, Christian Brunner wrote:
>
Hi,
I'm testing a file system with 10 osd daemons,
1 mds daemon, 1 mon daemon.
Client code is 2.6.36 + current for-linus branch
Server code is unstable branch, 2a3e73bb325f.
After mounting 64 clients, I had each write its own 512 MiB
file with dd, with all files being created in the same direct
On Tue, 26 Oct 2010, Christian Brunner wrote:
> When accessing multiple RBD-Volumes from one VM in parallel, we are
> receiving an assertion:
>
> ./osd/OSDMap.h: In function 'entity_inst_t OSDMap::get_inst(int)':
> ./osd/OSDMap.h:460: FAILED assert(exists(osd) && is_up(osd))
Can you change that i
Yes, one OSD crashed approximately an hour before this was happening.
Christian
-Ursprüngliche Nachricht-
Von: gr...@hq.newdream.net [mailto:ceph-devel-ow...@vger.kernel.org] Im Auftrag
von Gregory Farnum
Gesendet: Dienstag, 26. Oktober 2010 20:00
An: Christian Brunner
Cc: ceph-devel@vge
I can't promise this for tomorrow, but I think I can do this on Thursday.
Christian
-Ursprüngliche Nachricht-
Von: Sage Weil [mailto:s...@newdream.net]
Gesendet: Dienstag, 26. Oktober 2010 21:09
An: Christian Brunner
Cc: ceph-devel@vger.kernel.org
Betreff: Re: ./osd/OSDMap.h:460: FAILED
Does someone know which commit this is? I don't want to switch to the unstable
branch at the moment.
Christian
-Ursprüngliche Nachricht-
Von: Smets, Jan (Jan) [mailto:jan.sm...@alcatel-lucent.com]
Gesendet: Dienstag, 26. Oktober 2010 14:37
An: Christian Brunner
Betreff: RE: osd/Replica
On Tue, 26 Oct 2010, Jim Schutt wrote:
> Hi,
>
> I'm testing a file system with 10 osd daemons,
> 1 mds daemon, 1 mon daemon.
>
> Client code is 2.6.36 + current for-linus branch
> Server code is unstable branch, 2a3e73bb325f.
>
> After mounting 64 clients, I had each write its own 512 MiB
> fi
We recently hit an issue with xattrs on different underlying
filesystems. The basic problem is that we use xattrs for various
metadata information that we attach to the different objects, and for
some cases it tends to grow to relatively large sizes. It appears that
the various underlying filesyste
Hi,
On Tue, 2010-10-26 at 13:25 -0600, Sage Weil wrote:
> On Tue, 26 Oct 2010, Jim Schutt wrote:
> > Hi,
> >
> > I'm testing a file system with 10 osd daemons,
> > 1 mds daemon, 1 mon daemon.
> >
> > Client code is 2.6.36 + current for-linus branch
> > Server code is unstable branch, 2a3e73bb325f
Hi all,
I moved a file, and added anew GTK-related macro. So you may need to
re-run autogen.sh the next time you pull the unstable branch.
If you get an error about not being able to find ceph.o, you have hit this.
cheers,
Colin
--
To unsubscribe from this list: send the line "unsubscribe ceph-d
12 matches
Mail list logo