Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zsys cannot handle large amounts of snapshots #224

Open
kimono-koans opened this issue Feb 22, 2022 · 0 comments
Open

zsys cannot handle large amounts of snapshots #224

kimono-koans opened this issue Feb 22, 2022 · 0 comments

Comments

@kimono-koans
Copy link

From #172

You have 4300+ snapshots under the name "zfs-auto-snap-*" and you hit the go-libzfs limit in terms of performance.

As I think you don’t really need them as ZSys is performing the same kind of work, I suggest that you delete them all (and uninstall/remove the tool that create them). Then, ZSys should be performing correctly again. Please keep us posted if that worked out for you :)

First, I appreciate your work on zsys. I'm just trying zsys out on a new system and the basic functionality is great. However, I hit this same issue, and this seems like broken behavior to me. zsys shouldn't fall over when it encounters a few more snapshots than it is expecting. Is there an issue with just ignoring non-zsys snaps? I don't know golang but I'd be pleased to take a look at resolving this issue.

Second, what is the use of several multiples of 10 of zsys snaps? Why not just keep the last 10? Or at least have a configurable policy?

Third, a small UUID is fine, but why not include a timestamp in the snap name as well? I think that would be very helpful to the user.

Again, pleased to try to implement some of this functionality, if that would be consonant with the project's goals. Timestamps and ignoring non-zsys snaps seems like they wouldn't require too much work. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant