Re: Qgroups are not applied when snapshotting a subvol?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-03-28 08:00, Marat Khalili wrote:
>> 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.
There are a couple of reasons I'm advocating the specific behavior I 
outlined:
1. It doesn't require any specific qgroup setup.  By definition, you can 
be 100% certain that the destination qgroup exists, and that you won't 
need to create new qgroups behind the user's back (given your 
suggestion, what happens when qgroup 1/N doesn't exist?).
2. Just because it's the default, doesn't mean that the subvolume can't 
be reassigned to a different qgroup.  This also would not remove the 
ability to assign a specific qgroup through the snapshot creation 
command.  This is arguably a general point in favor of having any 
default of course, but it's still worth pointing out.
3. Because BTRFS has COW semantics, the new snapshot should take up near 
zero space in the qgroup of it's parent.
4. This correlates with the behavior most people expect based on ZFS and 
LVM, which is that snapshots are tied to their parent.

At a minimum, it should belong to _some_ qgroup.  This could also be 
covered by having a designated 'default' qgroup that all new subvolumes 
created without a specified qgroup get put in, but I feel that that is 
somewhat orthogonal to the issue of how snapshots are handled.

> --
>
> 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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html