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

[trivial] Check for # of subvolumes #33

Open
sten0 opened this issue May 29, 2017 · 3 comments
Open

[trivial] Check for # of subvolumes #33

sten0 opened this issue May 29, 2017 · 3 comments

Comments

@sten0
Copy link
Contributor

sten0 commented May 29, 2017

Hi Dave,

It just occurred to me that btrfsmaintenance might be a good place to globally check if the number of subvolumes is getting out of control. At the very least, this proposal will produce an alert if a periodic job fails to maintain a sane snapshot count. I believe that it will increase the likelihood of positive outcomes for those who try out btrfs, while ignorant to the inverse correlation between too-many-snapshots and performance and likelihood of ENOSPC. The method I thought of is simple, but might be too simplistic. Something like:

SUBVOLUME_LIMIT=300
for i in $BTRFS_DEFRAG_PATHS; do
sub_count=btrfs sub list -a $i | wc -l
if [ $sub_count -gt $SUBVOLUME_LIMIT ]; then
exceeded=expr $sub_count - $SUBVOLUME_LIMIT
echo "Warning: Subvolume limit for $i exceeds $SUBVOLUME_LIMIT by $exceeded subvolumes" | mail -s "Btrfs warning for $i" root@localhost
fi
done

To avoid adding another variable to sysconfig.btrfsmaintenance $i should be associated with the operation most likely to cause an ENOSPC or performance issue...but it might merit it's own configuration knob. If you answer these questions I'd be happy to prepare a formal patch.

Sincerely,
Nicholas

@sten0
Copy link
Contributor Author

sten0 commented May 29, 2017

P.S. And it also might be worth checking $SNAPSHOT_LIMIT for btrfs sub list -s $i, where that limit is either 8 or 12 ( https://btrfs.wiki.kernel.org/index.php/Gotchas#Having_many_subvolumes_can_be_very_slow ).

@kdave
Copy link
Owner

kdave commented Nov 8, 2017

So this could be a health monitoring, based on subvolume count in this case. I'm not sure if we can find some defaults that would fit most users, so this will be probably only optional and relies on the user configuration "abilities".

@sten0
Copy link
Contributor Author

sten0 commented Nov 9, 2017

Are you working on this or should I try to work on something that can be reused for #30 ? eg: something that can use special case SUBVOLUME_LIMIT="snapper", where that case executes a snapper_analyze function like the one you've proposed, uses snapper locations instead of generic $BTRFS_DEFRAG_PATHS, and uses the snapper_propose function from #30 instead of my simplistic if;then ? [p.s. I would write stubs]

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