On Tue, Jun 16, 2015 at 11:53 AM, Jan Schermer j...@schermer.cz wrote:
Well, I see mons dropping out when deleting large amount of snapshots, and it
leats a _lot_ of CPU to delete them
Well, you're getting past my expertise on the subject, but deleting
snapshots can sometimes be expensive,
On 16 Jun 2015, at 12:59, Gregory Farnum g...@gregs42.com wrote:
On Tue, Jun 16, 2015 at 11:53 AM, Jan Schermer j...@schermer.cz wrote:
Well, I see mons dropping out when deleting large amount of snapshots, and
it leats a _lot_ of CPU to delete them
Well, you're getting past my
Ping :-)
Looks like nobody is bothered by this, can I assume it is normal, doesn’t hurt
anything and will grow to millions in time?
Jan
On 15 Jun 2015, at 10:32, Jan Schermer j...@schermer.cz wrote:
Hi,
I have ~1800 removed_snaps listed in the output of “ceph osd dump”.
Is that
On Tue, Jun 16, 2015 at 12:03 PM, Jan Schermer j...@schermer.cz wrote:
On 16 Jun 2015, at 12:59, Gregory Farnum g...@gregs42.com wrote:
On Tue, Jun 16, 2015 at 11:53 AM, Jan Schermer j...@schermer.cz wrote:
Well, I see mons dropping out when deleting large amount of snapshots, and
it leats
On Tue, Jun 16, 2015 at 3:30 AM, Jan Schermer j...@schermer.cz wrote:
Thanks for the answer.
So it doesn’t hurt performance if it grows to ridiculous size - e.g. no
lookup table overhead, stat()ing additional files etc.?
Nope, definitely nothing like that. If it gets sufficiently fragmented
Every time you delete a snapshot it goes in removed_snaps. The set of
removed snaps is stored as an interval set, so it uses up two integers
in the OSDMap for each range.
There are some patterns of usage that work out badly for this, but
generally if you're creating snapshots as time goes forward
Thanks for the answer.
So it doesn’t hurt performance if it grows to ridiculous size - e.g. no lookup
table overhead, stat()ing additional files etc.?
Jan
On 16 Jun 2015, at 11:51, Gregory Farnum g...@gregs42.com wrote:
Every time you delete a snapshot it goes in removed_snaps. The set of
