Re: snaptrim number of objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> This also leads me to agree with you there's 'something wrong' with
> the mclock scheduler. I was almost starting to suspect hardware issues
> or something like that, I was at my wit's end.
Could you update this thread with the exact quincy version by running:

$ ceph versions


$ ceph config show-with-defaults osd.N | grep osd_mclock

Please replace N with any valid OSD id.

I suspect that the quincy version you are running on doesn't
have the latest changes we made to the Reef upstream release.
Recent changes introduced significant improvements to the
mClock profiles and address slow recovery/backfill rates. The
improvements to the mClock profiles should also help throttle
snaptrim operations.

Snaptrim operation with mClock currently uses a static cost as
defined by osd_snap_trim_cost. There are improvements planned
around this soon. For e.g., the cost must be dynamic and reflect
the size of the object being trimmed.
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]

  Powered by Linux