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

Periodic deduplication using BEES #127

Open
Eonfge opened this issue Sep 23, 2024 · 3 comments
Open

Periodic deduplication using BEES #127

Eonfge opened this issue Sep 23, 2024 · 3 comments

Comments

@Eonfge
Copy link

Eonfge commented Sep 23, 2024

Looking at all the possible features that BTRFS has, I was impressed to discover how much deduplication can matter. Sadly, there is no easy way for users to configure a periodic deduplication.

Looking at all the periodic scripts that this project provides, periodic deduplication might be a right fit for it.

Details

I would propose the use of BEES, and not Duperemove because BEES works on a block level. It will therefore not be as efficient as a file-based deduplication system, but it would be more suitable for general usage.

As with most of the scripts within this project, it would be worthwhile to look for a sensible default that doesn't drain to many resources while running.

@kdave
Copy link
Owner

kdave commented Jan 23, 2025

I think BEES may not suitable for the maintenance task (otherwise it's a great tool), or it could be tricky to configure and set up so it can run. Other tasks are simply start and wait until it ends, wihle Bees has many tunables. It seems to me it would be more suitable for custom user configuration because the /etc/sysconfig way is too simple. Also Bees comes with it's .service and beesd.

This could be done but I'm not sure how exactly to define the common use cases and provide reasonable configuration options or presets.

@kdave
Copy link
Owner

kdave commented Jan 23, 2025

Regarding duperemove, it's similar to the defrag task but again the number of options can make it hard for configuration in the /etc/sysconfig directory. The problem is that each path could require its own set of command line options and this is becomes cumbersome to track in shell variables.

@kdave
Copy link
Owner

kdave commented Jan 23, 2025

An idea: provide templates for .service or .timer units with various predefined use cases and descriptions. This can be a middle ground between the customizability and a single source of almost-ready-to-use units where a user can pick a suitable one and install it to systemd. If the units are simply stored in this git repo there's not much risk breaking existing systems.

@kdave kdave added the RFC label Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants