Sorry, just one more question:
Why is pginfo truncated every time a write is performed to the PG?
Thanks,
Christian
2011/11/24 Christian Brunner <chb@xxxxxx>:
> Hmmm, OK. - This really seems to belong to one virtual machine, that
> is writing to a single object over and over again.
>
> Thanks for your hint. I guess I will have to look into the VM.
>
> Christian
>
>
>
> 2011/11/24 Gregory Farnum <gregory.farnum@xxxxxxxxxxxxx>:
>> PGInfos are updated on disk with every write to the PG. I'm surprised
>> that one PG has so much more activity than the others, but that's why
>> that inode has so much activity.
>>
>> What are you doing with this installation, and roughly how many PGs
>> are on the node?
>>
>> On Thu, Nov 24, 2011 at 3:33 AM, Christian Brunner <chb@xxxxxx> wrote:
>>> I'm running a btrfs-debug patch on one of our nodes. This patch prints
>>> calls to btrfs_orphan_add. I'm still waiting for the problem the patch
>>> was intended to trace, but in the logs I found something ceph related
>>> I don't understand:
>>>
>>> When I look at the btrfs_orphan_add messages there is one inode that
>>> is updated over and over again. When I count the inodes in my log, I
>>> can see the following distribution (only inodes with more than 500
>>> btrfs_orphan_add calls listed):
>>>
>>> #cnt Inode
>>> 1117 7403
>>> 17218 7457
>>> 848 7484
>>> 539 7984
>>> 1446 9098
>>> 635 9346
>>>
>>> When I look at the filesysteme, I can see that inode 7457 belongs to:
>>>
>>> current/meta/DIR_8/DIR_A/pginfo\u2.8d__0_28D2BFA8
>>>
>>> I don't know how the pginfo stuff works, but I really wonder why the
>>> distribution is so uneven.
>>>
>>> "strace -f | grep 28D2BFA8" is giving me the this output:
>>>
>>> [...]
>>> [pid 3840] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
>>> [pid 3840] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
>>> [pid 3840] truncate("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> 0) = 0
>>> [pid 3840] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>> [pid 3840] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>> [pid 3840] open("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> O_WRONLY|O_CREAT, 0644) = 64
>>> [pid 3841] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
>>> [pid 3841] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
>>> [pid 3841] truncate("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> 0) = 0
>>> [pid 3841] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>> [pid 3841] stat("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>> [pid 3841] open("/ceph/osd.015/current/meta/DIR_2/pginfo\\u2.d6__0_28D16932",
>>> O_WRONLY|O_CREAT, 0644) = 64
>>> [...]
>>>
>>> Regards,
>>> Christian
>>> --
>>> 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
>>>
>> --
>> 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
>>
>
--
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
