search

kdave / btrfsmaintenance

Scripts for btrfs maintenance tasks like periodic scrub, balance, trim or defrag on selected mountpoints or directories.
GNU General Public License v2.0
900 stars 79 forks source link

[trivial] Check for # of subvolumes #33

Open sten0 opened 7 years ago

sten0 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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]