Hi sur5r, Am 4/27/23 um 10:33 schrieb Jakob Haufe:

On Thu, 27 Apr 2023 09:07:10 +0200 Tobias Hachmer <t.hachmer@s-v.de> wrote:

...

But we observed that max 50 snapshot are preserved. If a new snapshot is created the oldest 51st is deleted.

Is there a limit for maximum cephfs snapshots or maybe this is a bug?

I've been wondering the same thing for about 6 months now and found the reason just yesterday.

The snap-schedule mgr module has a hard limit on how many snapshots it preserves, see [1]. It's even documented at [2] in section "Limitations" near the end of the page.

The commit[3] implementing this does not only not explain the reason for the number at all, it doesn't even mention the fact it implements this.

Thanks. I've red the documentation, but it's not clear enough. I thought "the retention list will be shortened to the newest 50 snapshots" will just truncate the list and not delete the snapshots, effectively. So as you stated the max. number of snapshots is currently a hard limit. Can anyone clarify the reasons for this? If there's a big reason to hard limit this it would be great to schedule snapshots more granular e.g. mo-fr every two hours between 8am-6pm.

Given the limitation is per directory, I'm currently trying this:

/ 1d 30d /foo 1h 48h /bar 1h 48h

I forgot to activate the new schedules yesterday so I can't say whether it works as expected yet.

Please let me know if this works. Thanks, Tobias

On Thu, 27 Apr 2023 11:10:07 +0200 Tobias Hachmer <t.hachmer-YT5KBw9Z7BM@public.gmane.org> wrote:

...

Given the limitation is per directory, I'm currently trying this:

/ 1d 30d /foo 1h 48h /bar 1h 48h

I forgot to activate the new schedules yesterday so I can't say whether it works as expected yet.

Please let me know if this works.

It doesn't. I haven't re-visited the code yet, but for some reason the lower level schedules get deactivated again, seemingly each time they are supposed to create a snapshot. Cheers, sur5r -- ceterum censeo microsoftem esse delendam.

On Fri, 28 Apr 2023 22:46:32 +0530 Milind Changire wrote:

If a dir doesn't exist at the moment of snapshot creation, then the schedule is deactivated for that dir.

Ha! Good catch! As often, I completely forgot about the /volumes prefix... -- ceterum censeo microsoftem esse delendam.

FYI, PR - https://github.com/ceph/ceph/pull/51278 On Fri, Apr 28, 2023 at 8:49 AM Milind Changire <mchangir@redhat.com> wrote:

There's a default/hard limit of 50 snaps that's maintained for any dir via the definition MAX_SNAPS_PER_PATH = 50 in the source file src/pybind/mgr/snap_schedule/fs/schedule_client.py. Every time the snapshot names are read for pruning, the last thing done is to check the length of the list and keep only MAX_SNAPS_PER_PATH and the rest are pruned.

Jakob Haufe has pointed it out correctly.

On Thu, Apr 27, 2023 at 12:38 PM Tobias Hachmer <t.hachmer@s-v.de> wrote:

...

Hello,

we are running a 3-node ceph cluster with version 17.2.6.

For CephFS snapshots we have configured the following snap schedule with retention:

/PATH 2h 72h15d6m

But we observed that max 50 snapshot are preserved. If a new snapshot is created the oldest 51st is deleted.

Is there a limit for maximum cephfs snapshots or maybe this is a bug?

I have found the setting "mds_max_snaps_per_dir" which is 100 by default but I think this is not related to my problem?

Thanks,

Tobias _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

-- Milind

-- Milind