On Tue, Jul 31, 2018 at 22:32:07 +0800, Qu Wenruo wrote:
> 2) Different limitations on exclusive/shared bytes
> Btrfs can set different limit on exclusive/shared bytes, further
> complicating the problem.
>
> 3) Btrfs quota only accounts data/metadata used by the subvolume
> It lacks all the shared trees (mentioned below), and in fact such
> shared tree can be pretty large (especially for extent tree and csum
> tree).
I'm not sure about the implications, but just to clarify some things:
when limiting somebody's data space we usually don't care about the
underlying "savings" coming from any deduplicating technique - these are
purely bonuses for system owner, so he could do larger resource overbooking.
So - the limit set on any user should enforce maximum and absolute space
he has allocated, including the shared stuff. I could even imagine that
creating a snapshot might immediately "eat" the available quota. In a
way, that quota returned matches (give or take) `du` reported usage,
unless "do not account reflinks withing single qgroup" was easy to implemet.
I.e.: every shared segment should be accounted within quota (at least once).
And the numbers accounted should reflect the uncompressed sizes.
Moreover - if there would be per-subvolume RAID levels someday, the data
should be accouted in relation to "default" (filesystem) RAID level,
i.e. having a RAID0 subvolume on RAID1 fs should account half of the
data, and twice the data in an opposite scenario (like "dup" profile on
single-drive filesystem).
In short: values representing quotas are user-oriented ("the numbers one
bought"), not storage-oriented ("the numbers they actually occupy").
--
Tomasz Pala <gotar@xxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
