Ignore this, it was operator error. Everything appears on the expected OSDs.
And I assume when I see an op with a description like
"MOSDECSubOpRead(3.23s1 305 ECSubRead..."
that this is the reading of the second chunk in a k=2,m=1 erasure pool?
-- Tom
> -----Original Message-----
> From: Deneau, Tom
> Sent: Monday, January 25, 2016 4:54 PM
> To: ceph-devel@xxxxxxxxxxxxxxx
> Cc: cbt@xxxxxxxxxxxxxx
> Subject: historic ops showing up on unexpected osds
>
> I was looking at a performance discrepancy with reading objects
> and I was looking at some historic ops and noticed several like this.
> This is an erasure pool with k=2, m=1 so 3 chunks for each object.
>
> When I look at the pg mapping for this object shown below on this pool,
> it is [12,14,6].
> And indeed when I look at the actual pieces on disk, they are on the disks
> that map to osds 12, 14, and 6.
>
> Yet this osd for which this particular historic op showed up was osd 11.
> And I have seen other historic ops mapped to this same pg, which showed up
> for instance on osd 15.
> Why would osd 11 or ods 15 be involved in this object at all?
>
> -- Tom
>
>
> {
> "description": "osd_op(client.13056.0:2691 0-ggggjbjm []
> 3.a3ebd1b8 ack+read+known_if_redirected e305)",
> "initiated_at": "2016-01-25 13:01:15.824133",
> "age": 60.812474,
> "duration": 8.913674,
> "type_data": [
> "started",
> {
> "client": "client.13056",
> "tid": 2691
> },
> [
> {
> "time": "2016-01-25 13:01:15.824133",
> "event": "initiated"
> },
> {
> "time": "2016-01-25 13:01:15.824258",
> "event": "queued_for_pg"
> },
> {
> "time": "2016-01-25 13:01:23.056172",
> "event": "reached_pg"
> },
> {
> "time": "2016-01-25 13:01:23.082064",
> "event": "started"
> },
> {
> "time": "2016-01-25 13:01:24.737807",
> "event": "done"
> }
> ]
> ]
> },
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
