Btrfs quota support

I fully support this!

As the architect of multiple of my company's cPanel solutions, I have already created a "hacky" solution that leverages cPanel's quota cache files (/var/cpanel/repquota.datastore and the per-cPanel user homedir datastore cache files) to convey BTRFS qgroup usage information to cPanel/WHM. At the moment, this also involves adding all disk quota scripts like /scripts/fixquotas to /etc/cpanelsync.exclude (which does not seem to be respecting this for many of these files) and deleting the scripts outright and then touch + chattr +ia'ing them. But the solution itself works exceptionally well, barring a rework of cPanel's quota cache system, the only outstanding issues I have with my implementation can be resolved with minor adjustments.

I would like to quickly convey helpful implementation details/snags to reduce the difficulty cPanel will run into with this:

• Modify account creation when BTRFS is enabled on the target homedir for the account to create a BTRFS subvolume as the account's home directory (this will automatically create a qgroup for the subvolume)
• Architect your system to run btrfs qgroup show --human-readable -r /homedir as little as possible and to parse + cache the output. When the number of qgroups grows large, trying to run this command per-user is overly slow, but parsing and caching the data it outputs is very fast (at least with the Node.JS implementation I created)
• For additional clarification, I parsed this data into a JSON structure- { "subvolid": { "rfer": rfer, "max_rfer": max_rfer }}, and when I update this to make the cache durable (on-disk), I will match an array of cPanel users' homedir subvolume IDs to match against "subvolid" to cull non-cPanel user qgroups from object before writing the object to disk (doing this in-memory is quick)
• cPanel-level quota caching may need a slight rework. Because qgroups work based on location rather than owner, when an account exceeds its quota, cPanel cannot write to the account's quota cache files, so cPanel will not reflect this. I will shortly be testing an adjustment to this whereby the cache files do not exist in the cPanel users' homedir but instead exist elsewhere and are symlinked to the user's homedir to see if this can correct the issue (I can't see why it wouldn't but we'll see!)
• I strongly suspect that a BTRFS quota implementation could entirely forgo interacting with Quota.pm at all, which may end up being beneficial towards removing legacy "cruft" if any exists and being able to focus on allowing BTRFS quota implementations to leverage strong parallelism (with my Node.JS implementation, I have been using a C&C thread to dispatch per-user quota operations and to limit those to the number of physical CPU cores on the system, and that approach has worked extremely well for keeping execution time down and for not impacting the server's actual CPU usage much- load looks a tad brutal when my setup runs, but sar -u shows that is only because of the number of processes running in the R or D state, not due to the CPU or IO actually being overwhelmed)
• Modify account removal when BTRFS is enabled on the target homedir for the account to read the subvolume ID of the homedir into memory, to btrfs subvolume delete the homedir, and to btrfs qgroup destroy the subvolume's qgroup

I can provide the source code for my existing solution directly to cPanel if it would assist in expediting implementation of a solution for this.

Quota support really is all that is necessary for cPanel to support BTRFS, but I would also love if cPanel would look longer-term at BTRFS support as well that leverages some of the unique features of the filesystem over EXT4/XFS. Besides the quota setup I made, I have also developed a backup system that leverages pkgacct to take homeless backups of cPanel accounts and to use incremental BTRFS snapshots to backup homedirs to the /backup mount. For servers with only a single volume, this would make backups nearly instantaneous. For servers with a mounted or networked backup drive, an instantaneous ACOW snapshot can be made locally (at basically zero disk cost) and btrfs send -p can be used to send incremental snapshots to the mounted/networked backup drive (assuming that is running BTRFS as well). This has the added benefit on the /backup mount/network locale of being able to have the speed advantages of incremental backups but the redundancy benefits of non-incremental (I can explain this more if requested). If cPanel were to take this on, I suspect pkgacct could be updated as well to leverage BTRFS's advanced capabilities to fetch/save cPanel structural data more quickly and effectively.

As with quota support, I am more than happy to share source code/implementation details/etc for backing up cPanel accounts with BTRFS.

Because Btrfs does not support user-quotas and uses a subvolume quota model, quotas should not be expected to work exactly the same on Btrfs as they do on other filesystems. Similar functionality can be approximated by creating a new subvolume for each user's home directory and configuring subvolume quotas.