The default should be to inherit the qgroup of the parent subvolume.
This behaviour is only good for this particular use-case. In general
case, qgroups of subvolume and snapshots should exist separately, and
both can be included in some higher level qgroup (after all, that's what
qgroup hierarchy is for).
In my system I found it convenient to include subvolume and its
snapshots in qgroup 1/N, where 0/N is qgroup of bare subvolume. I think
adopting this behaviour as default would be more sensible.
--
With Best Regards,
Marat Khalili
On 28/03/17 14:24, Austin S. Hemmelgarn wrote:
On 2017-03-27 15:32, Chris Murphy wrote:
How about if qgroups are enabled, then non-root user is prevented from
creating new subvolumes?
Or is there a way for a new nested subvolume to be included in its
parent's quota, rather than the new subvolume having a whole new quota
limit?
Tricky problem.
The default should be to inherit the qgroup of the parent subvolume.
The organization of subvolumes is hierarchical, and sane people expect
things to behave as they look. Taking another angle, on ZFS, 'nested'
(nested in quotes because ZFS' definition of 'nested' zvols is weird)
inherit their parent's quota and reservations (essentially reverse
quota), and they're not even inherently nested in the filesystem like
subvolumes are, so we're differing from the only other widely used
system that implements things in a similar manner.
As far as the subvolume thing, there should be an option to disable
user creation of subvolumes, and ideally it should be on by default
because:
1. Users can't delete subvolumes by default. This means they can
create but not destroy a resource by default, which means that a user
can pretty easily accidentally cause issues for the system as a whole.
2. Correlating with 1, users being able to delete subvolumes by
default is not safe on multiple levels (easy accidental data loss,
numerous other issues), and thus user subvolume removal being off by
default is significantly safer.
--
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
--
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
