Hello,
The behavior of 'cp --reflink' puzzles me from the quota point of view.
It looks like it's possible to easily exceeds a qgroup's max_rfer limit
like this:
~# # Create '/test' and '/test/a' subvolumes
~# btrfs subvolume create /test
~# btrfs subvolume create /test/a
~#
~# # Set limits
~# btrfs qgroup limit 10m (qgroupid) /
~# btrfs qgroup limit -e 5m (qgroupid) /
~#
~# # Limits are set
~# btrfs qgroup show -erF /test/a/
qgroupid rfer excl max_rfer max_excl
-------- ---- ---- -------- --------
(the id) 16.00KiB 16.00KiB 10.00MiB 5.00MiB
~#
~# # Write a big file in '/test'
~# dd if=/dev/urandom of=/test/bigfile bs=1M count=50
~#
~# # Copy it to '/test/a' using cp --reflink
~# cp --reflink /test/bigfile /test/a
~#
~# # No EDQUOT error, quota limit is exceeded
~# btrfs qgroup show --sync -erF /test/a/
qgroupid rfer excl max_rfer max_excl
-------- ---- ---- -------- --------
(the id) 50.02MiB 16.00KiB 10.00MiB 5.00MiB
~#
However, now the limit is exceeded, EDQUOT is raised upon a new 'cp
--reflink':
~# touch /test/nothing
~# cp --reflink /test/nothing /test/a
cp: cannot create regular file 'a/nothing': Disk quota exceeded
~#
As far as I understand the code, btrfs_clone doesn't try to reserve data
it clones. It only reserves metadata through btrfs_start_transaction.
Is it an expected behavior?
Regards,
--
Antoine
--
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
