On 2017-02-07 20:49, Nicholas D Steeves wrote:
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?
AFAIK, it's 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.
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.
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
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
