user_subvol_rm_allowed? Is there a user_subvol_create_deny|allowed?

Dear btrfs community,

Please accept my apologies in advance if I missed something in recent btrfs development; my MUA tells me I'm ~1500 unread messages out-of-date. :/

I recently read about "mount -t btrfs -o user_subvol_rm_allowed" while doing reading up on LXC handling of snapshots with the btrfs backend. Is this mount option per-subvolume, or per volume?

Also, what mechanisms to restrict a user's ability to create an arbitrarily large number of snapshots? Is there a user_subvol_create_deny|allowed? What I've read about the inverse correlation between number of subvols to performance, a potentially hostile user could cause an IO denial of service or potentially even trigger an ENOSPC.

From what I gather, the following will reproduce the hypothetical issue related to my question:

# as root
btrfs sub create /some/dir/subvol
chown some-user /some/dir/subvol

# as some-user
cd /home/dir/subvol
cp -ar --reflink=always /some/big/files ./
COUNT=1
while [ 0 -lt 1 ]; do
  btrfs sub snap ./ ./snapshot-$COUNT
  COUNT=COUNT+1
  sleep 2   # --maybe unnecessary
done

--

I hope there's something I've misunderstood or failed to read!

Please CC me so your reply will hit my main inbox :-) Nicholas

AFAIK, it's per-volume.

Currently, there is nothing that restricts this ability. This is one of a handful of outstanding issues that I'd love to see fixed, but don't have the time, patience, or background to fix it myself.

fWIW, this will cause all kinds of other issues too. It will however slow down exponentially over time as a result of these issues though. The two biggest are:
1. Performance for large directories is horrendous, and roughly exponentially (with a small exponent near 1) proportionate to the inverse of the number of directory entries. Past a few thousand entries, directory operations (especially stat() and readdir()) start to take long enough for a normal person to notice the latency.
2. Overall filesystem performance with lots of snapshots is horrendous too, and this also scales exponentially proportionate to the inverse of the number of snapshots and the total amount of data in each. This will start being an issue much sooner than 1, somewhere around 300-400 snapshots most of the time.