linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Non-existent qgroup in parent-child relation prevents makes qgroup commands fail
Date: Sat, 3 Aug 2019 08:31:26 +0300	[thread overview]
Message-ID: <96f2509f-fd4b-ed5c-7e48-730d3a9875f5@gmail.com> (raw)
In-Reply-To: <5dcb6a1b-42db-cc84-a403-288b30c2842b@gmx.com>


[-- Attachment #1.1: Type: text/plain, Size: 3780 bytes --]

03.08.2019 2:09, Qu Wenruo пишет:
> 
> 
> On 2019/8/3 上午2:08, Andrei Borzenkov wrote:
>> bor@tw:~> sudo btrfs qgroup show .
>> ERROR: cannot find the qgroup 0/789
>> bor@tw:~>
>>
>> Fine. This openSUSE with snapper which creates and automatically
>> destroys snapshots and apparently either kernel or snapper now also
>> remove corresponding qgroup. I played with snapshots and created several
>> top level qgroups that included snapshot qgroups existing at this time.
>> Now these snapshots are gone, their qgroups are gone ...
> 
> Kernel version please.
> 
> IIRC latest upstream kernel doesn't remove the level 0 qgroup.

Yes?

> It may be the userspace doing it improperly.
> 

Not sure what "improperly" means here. snapper removes qgroup after
deleting snapshot. What is "improper" here?

Snapper obviously does not track every parent-child relationship beyond
what it itself cares about (single summary qrgoup that includes all
snapshots).

>> and what can I
>> do? I have no way to even know what is wrong because the very command
>> that shows it fails immediately.
>>
>> bor@tw:~/python-btrfs/examples> sudo ./show_tree_keys.py 8 . | grep 0/789
>> (0/789 QGROUP_RELATION 2/792)
>> (0/789 QGROUP_RELATION 2/793)
>> (0/789 QGROUP_RELATION 2/795)
>> (0/789 QGROUP_RELATION 2/799)
>> (0/789 QGROUP_RELATION 2/800)
>> (0/789 QGROUP_RELATION 2/803)
>> (0/789 QGROUP_RELATION 2/804)
>> (0/789 QGROUP_RELATION 2/805)
>> (0/789 QGROUP_RELATION 2/806)
>> (0/789 QGROUP_RELATION 2/807)
>> (0/789 QGROUP_RELATION 2/808)
>> (0/789 QGROUP_RELATION 2/809)
>> (0/789 QGROUP_RELATION 2/814)
>> (0/789 QGROUP_RELATION 2/818)
>> (0/789 QGROUP_RELATION 2/819)
>> (2/792 QGROUP_RELATION 0/789)
>> (2/793 QGROUP_RELATION 0/789)
>> (2/795 QGROUP_RELATION 0/789)
>> (2/799 QGROUP_RELATION 0/789)
>> (2/800 QGROUP_RELATION 0/789)
>> (2/803 QGROUP_RELATION 0/789)
>> (2/804 QGROUP_RELATION 0/789)
>> (2/805 QGROUP_RELATION 0/789)
>> (2/806 QGROUP_RELATION 0/789)
>> (2/807 QGROUP_RELATION 0/789)
>> (2/808 QGROUP_RELATION 0/789)
>> (2/809 QGROUP_RELATION 0/789)
>> (2/814 QGROUP_RELATION 0/789)
>> (2/818 QGROUP_RELATION 0/789)
>> (2/819 QGROUP_RELATION 0/789)
>> bor@tw:~/python-btrfs/examples>
>>
>> And even if I find it out, I cannot fix it anyway
> 
> Furthermore, latest kernel should automatically remove the relation when
> deleting the qgroup.
> 

Yes, seems to be the case now with 5.2.3.

> Would you please provide the (minimal) script/reproducer causing the
> situation and kernel version?
> 

I cannot reproduce it on purpose with kernel 5.2.3 and btrfsprogs 5.1. I
do not remember when I created the configuration in question, it
probably was late 4.x or early 5.x. System was periodically updated
since then and I noticed it only now.

Actually kernel should be dropping parent-child relation when removing
child since kernel 4.1 (commit
f5a6b1c53bdd44f79e3904c0f5e59f956b49b2c8). May be there is (was) some
other code path that skipped it.

OTOH this is not atomic. First qgroup item itself is removed, then
relation. If removing relation fails for whatever reason item itself is
already gone and we have situation above.

> Thanks,
> Qu
> 
>>
>> bor@tw:~/python-btrfs/examples> sudo btrfs qgroup remove 0/789 2/792 .
>> ERROR: unable to assign quota group: Invalid argument
>> bor@tw:~/python-btrfs/examples>
>>
>> I can remove parent qgroup, but it does not clean up parent-child
>> relationship
>>
>> bor@tw:~/python-btrfs/examples> sudo btrfs qgroup destroy 2/792 .
>> bor@tw:~/python-btrfs/examples> sudo ./show_tree_keys.py 8 . | grep 2/792
>> (0/789 QGROUP_RELATION 2/792)
>> (2/792 QGROUP_RELATION 0/789)
>> bor@tw:~/python-btrfs/examples>
>>
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2019-08-03  5:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02 18:08 Non-existent qgroup in parent-child relation prevents makes qgroup commands fail Andrei Borzenkov
2019-08-02 23:09 ` Qu Wenruo
2019-08-03  5:31   ` Andrei Borzenkov [this message]
2019-08-03  6:17     ` Qu Wenruo
2019-08-03  6:49       ` Andrei Borzenkov
2019-08-03  7:03         ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96f2509f-fd4b-ed5c-7e48-730d3a9875f5@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).