Hit "Send" a little too early:
More complete workaround would be delayed cleanup. What about
(re-)mount time? (Should also handle qgroups remaining
... after subvolumes deleted on previous kernels.)
--
With Best Regards,
Marat Khalili
On 23/05/17 08:38, Marat Khalili wrote:
Just some
Just some user's point of view:
I propose the following changes:
1) We always cleanup level-0 qgroups by default, with no opt-out.
I see absolutely no reason to keep these around.
It WILL break scripts that try to do this cleanup themselves. OTOH it
will simplify writing new ones.
Since
At 05/23/2017 04:54 AM, Sargun Dhillon wrote:
On Sun, May 21, 2017 at 5:59 PM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
At 05/19/2017 05:07 PM, Sargun Dhillon wrote:
I have some questions about the *intended* qgroups semantics, and why
we allow certain operations:
1) Why can you
On Sun, May 21, 2017 at 5:59 PM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
>
>
> At 05/19/2017 05:07 PM, Sargun Dhillon wrote:
>>
>> I have some questions about the *intended* qgroups semantics, and why
>> we allow certain operations:
>>
>> 1)
At 05/19/2017 05:07 PM, Sargun Dhillon wrote:
I have some questions about the *intended* qgroups semantics, and why
we allow certain operations:
1) Why can you create a level 0 qgroup for a non-existent subvolume?
It looks like it just gets reset when you create the subvol anyway?
Should we
I have some questions about the *intended* qgroups semantics, and why
we allow certain operations:
1) Why can you create a level 0 qgroup for a non-existent subvolume?
It looks like it just gets reset when you create the subvol anyway?
Should we prevent this?
2) Why do we allow deleting a level
