Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Su Yue <l@damenly.su>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Zhenyu Wu <wuzy001@gmail.com>, Graham Cobb <g.btrfs@cobb.uk.net>,
	linux-btrfs@vger.kernel.org
Subject: Re: [question] free space of disk with btrfs is too different from other du
Date: Fri, 25 Jun 2021 07:51:15 +0800	[thread overview]
Message-ID: <wnqiom4e.fsf@damenly.su> (raw)
In-Reply-To: <c2cc4d69-a631-8765-cc7e-dd1bd8960265@gmx.com>


On Fri 25 Jun 2021 at 07:33, Qu Wenruo <quwenruo.btrfs@gmx.com> 
wrote:

> On 2021/6/24 下午10:52, Zhenyu Wu wrote:
>> the extent.txt has been uploaded to 
>> <https://share.weiyun.com/1G0Vkvv5>
>>
>> thanks!
>>
>
> Sorry, could you upload it to google drive?
>
The download speepd of tecent disk even is even slower than my 
VPN.

https://drive.google.com/file/d/1HJzw7vvVDOz4EIpzjg1M2Dr5Y0YbzkgD/view?usp=sharing

--
Su

> I don't have any tencent account to download the file.
>
> Thanks,
> Qu
>
>> On Thu, Jun 24, 2021 at 10:38 PM Zhenyu Wu <wuzy001@gmail.com> 
>> wrote:
>>>
>>> ```
>>> $ btrfs ins dump-tree -t data_reloc
>>> btrfs-progs v5.10.1
>>> data reloc tree key (DATA_RELOC_TREE ROOT_ITEM 0)
>>> leaf 57458688 items 2 free space 16061 generation 941500 owner 
>>> DATA_RELOC_TREE
>>> leaf 57458688 flags 0x1(WRITTEN) backref revision 1
>>> fs uuid 644a9e91-5e05-4f5d-a79b-e0eccd21a1a8
>>> chunk uuid fa782e34-63ae-4917-ac63-bbbe56851d8b
>>> item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
>>> generation 3 transid 0 size 0 nbytes 16384
>>> block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0
>>> sequence 0 flags 0x0(none)
>>> atime 1579910090.0 (2020-01-24 23:54:50)
>>> ctime 1579910090.0 (2020-01-24 23:54:50)
>>> mtime 1579910090.0 (2020-01-24 23:54:50)
>>> otime 1579910090.0 (2020-01-24 23:54:50)
>>> item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
>>> index 0 namelen 2 name: ..
>>> total bytes 499972575232
>>> bytes used 466593501184
>>> uuid 644a9e91-5e05-4f5d-a79b-e0eccd21a1a8
>>> $ btrfs ins dump-tree -t root 2>&1|tee root.txt
>>> # attachment
>>> $ btrfs ins dump-tree -t extent 2>&1|tee extent.txt
>>> # it's too large, i'll upload it to a cloud disk
>>> ```
>>>
>>> thanks!
>>>
>>>
>>>
>>> On Thu, Jun 24, 2021 at 8:30 PM Qu Wenruo 
>>> <quwenruo.btrfs@gmx.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2021/6/24 下午7:33, Zhenyu Wu wrote:
>>>>> the output has changed. do i need `btrfs ins dump-tree -t 
>>>>> root`?
>>>>> ```
>>>>> $ sudo btrfs quota disable /
>>>>> $ sudo btrfs quota enable /
>>>>> $ sudo btrfs quota rescan -w /
>>>>> # after 22m11s
>>>>> $ sudo btrfs qgroup show -pcre /
>>>>> qgroupid         rfer         excl     max_rfer     max_excl 
>>>>> parent  child
>>>>> --------         ----         ----     --------     -------- 
>>>>> ------  -----
>>>>> 0/5          81.23GiB      6.90GiB         none         none 
>>>>> ---     ---
>>>>> ```
>>>>> thanks!
>>>>
>>>> Yes, dump tree output for both root and data_reloc is needed.
>>>>
>>>> There may be a larger dump needed, "btrfs ins dump-tree -t 
>>>> extent
>>>> <device>", as I guess there is some ghost trees not properly 
>>>> deleted at
>>>> all...
>>>>
>>>> The whole thing is going crazy now.
>>>>
>>>> Thanks,
>>>> Qu
>>>>>
>>>>> On Thu, Jun 24, 2021 at 6:07 PM Qu Wenruo 
>>>>> <quwenruo.btrfs@gmx.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2021/6/24 下午5:52, Zhenyu Wu wrote:
>>>>>>> i have rescan quota but it looks like nothing change...
>>>>>>> ```
>>>>>>> $ sudo btrfs quota rescan -w /
>>>>>>> quota rescan started
>>>>>>> # after 8m39s
>>>>>>> $ sudo btrfs qgroup show -pcre /
>>>>>>> qgroupid         rfer         excl     max_rfer 
>>>>>>> max_excl parent   child
>>>>>>> --------         ----         ----     -------- 
>>>>>>> -------- ------   -----
>>>>>>> 0/5          81.23GiB      6.89GiB         none 
>>>>>>> none ---      ---
>>>>>>> 0/265           0.00B        0.00B         none 
>>>>>>> none ---      ---
>>>>>>> 0/266           0.00B        0.00B         none 
>>>>>>> none ---      ---
>>>>>>> 0/267           0.00B        0.00B         none 
>>>>>>> none ---      ---
>>>>>>> 0/6482          0.00B        0.00B         none 
>>>>>>> none ---      ---
>>>>>>> 0/7501       16.00KiB     16.00KiB         none 
>>>>>>> none ---      ---
>>>>>>> 0/7502       16.00KiB     16.00KiB         none 
>>>>>>> none 255/7502 ---
>>>>>>> 0/7503       16.00KiB     16.00KiB         none 
>>>>>>> none 255/7503 ---
>>>>>>
>>>>>> This is now getting super weird now.
>>>>>>
>>>>>> Firstly, if there are some snapshots of subvolume 5, it 
>>>>>> should show up
>>>>>> here, with size over several GiB.
>>>>>>
>>>>>> Thus there seems to be some ghost/hidden subvolumes that 
>>>>>> even don't show
>>>>>> up in qgroup.
>>>>>>
>>>>>> It's possible that some qgroup is intentionally deleted, 
>>>>>> thus not being
>>>>>> properly updated.
>>>>>>
>>>>>> For that case, you may want to disable qgroup, re-enable, 
>>>>>> then do a
>>>>>> rescan: (Can all be done on the running system)
>>>>>>
>>>>>> # btrfs quota disable <mnt>
>>>>>> # btrfs quota enable <mnt>
>>>>>> # btrfs quota rescan -w <mnt>
>>>>>>
>>>>>> Then provide the output of 'btrfs qgroup show -prce <mnt>"
>>>>>>
>>>>>> If the output doesn't change at all, after the full 10min 
>>>>>> rescan, then I
>>>>>> guess you have to dump the root tree, along with the 
>>>>>> data_reloc tree.
>>>>>>
>>>>>> # btrfs ins dump-tree -t root <device>
>>>>>> # btrfs ins dump-tree -t data_reloc <device>
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>> 1/0             0.00B        0.00B         none 
>>>>>>> none ---      ---
>>>>>>> 255/7502     16.00KiB     16.00KiB         none 
>>>>>>> none ---      0/7502
>>>>>>> 255/7503     16.00KiB     16.00KiB         none 
>>>>>>> none ---      0/7503
>>>>>>> ```
>>>>>>>
>>>>>>> and i try to mount with option subvolid:
>>>>>>> ```
>>>>>>> $ mkdir /tmp/fulldisk
>>>>>>> $ sudo mount -o subvolid=5 /dev/sda2 /tmp/fulldisk
>>>>>>> $ ls -lA /tmp/fulldisk
>>>>>>> total 4
>>>>>>> drwxr-xr-x 1 root   root   1936 May  3 21:34 bin
>>>>>>> drwxr-xr-x 1 root   root      0 Jan 25  2020 boot
>>>>>>> drwxr-xr-x 1 root   root   1686 Jan 20  2020 dev
>>>>>>> drwxr-xr-x 1 wzy    wzy    5756 Jun 24 13:51 etc
>>>>>>> drwxr-xr-x 1 root   root     22 Oct 17  2020 home
>>>>>>> drwxr-xr-x 1 root   root   1332 May 18 14:13 lib
>>>>>>> drwxr-xr-x 1 root   root   6606 May 18 14:13 lib64
>>>>>>> lrwxrwxrwx 1 root   root     10 Jan 24 20:23 media -> 
>>>>>>> /run/media
>>>>>>> drwxr-xr-x 1 wzy    wzy      38 Jan 27 16:51 mnt
>>>>>>> drwxr-xr-x 1 root   root    234 Jun 18 14:29 opt
>>>>>>> drwxr-xr-x 1 root   root      0 Jan 20  2020 proc
>>>>>>> drwx------ 1 wzy    wzy     536 Jun 15 20:26 root
>>>>>>> drwxr-xr-x 1 root   root     48 May 30 14:14 run
>>>>>>> drwxr-xr-x 1 root   root   4926 May 18 14:12 sbin
>>>>>>> drwxr-xr-x 1 root   root     10 Jan 20  2020 sys
>>>>>>> drwxrwxrwx 1 nobody nobody    0 Jun 18 14:34 tftproot
>>>>>>> drwxrwxrwt 1 root   root      0 May 30 14:25 tmp
>>>>>>> drwxr-xr-x 1 root   root    198 Mar 31 19:32 usr
>>>>>>> drwxr-xr-x 1 root   root    150 Apr  1 18:21 var
>>>>>>> $ sudo btrfs fi du -s /tmp/fulldisk/*
>>>>>>>         Total   Exclusive  Set shared  Filename
>>>>>>>      10.66MiB       0.00B    10.66MiB  /tmp/fulldisk/bin
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/boot
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/dev
>>>>>>>      33.34MiB    36.00KiB    33.30MiB  /tmp/fulldisk/etc
>>>>>>>      13.79GiB   784.05MiB    12.96GiB  /tmp/fulldisk/home
>>>>>>>     922.28MiB       0.00B   922.28MiB  /tmp/fulldisk/lib
>>>>>>>      23.11MiB       0.00B    23.11MiB  /tmp/fulldisk/lib64
>>>>>>> ERROR: cannot check space of '/tmp/fulldisk/media': 
>>>>>>> Inappropriate
>>>>>>> ioctl for device
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/mnt
>>>>>>>      11.08GiB       0.00B    11.08GiB  /tmp/fulldisk/opt
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/proc
>>>>>>>      40.38MiB     4.35MiB    36.03MiB  /tmp/fulldisk/root
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/run
>>>>>>>      26.62MiB       0.00B    26.62MiB  /tmp/fulldisk/sbin
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/sys
>>>>>>>         0.00B       0.00B       0.00B 
>>>>>>>         /tmp/fulldisk/tftproot
>>>>>>>         0.00B       0.00B       0.00B  /tmp/fulldisk/tmp
>>>>>>>      47.22GiB     1.03GiB    46.15GiB  /tmp/fulldisk/usr
>>>>>>>       5.80GiB     4.35GiB     1.45GiB  /tmp/fulldisk/var
>>>>>>> ```
>>>>>>>
>>>>>>> because media is a symbolic link so the ERROR should be 
>>>>>>> normal.
>>>>>>> according to `btrfs fi du` it looks like i only use about 
>>>>>>> 80GiB. it is
>>>>>>> too weird.
>>>>>>> thanks!
>>>>>>>
>>>>>>> On Thu, Jun 24, 2021 at 4:32 PM Graham Cobb 
>>>>>>> <g.btrfs@cobb.uk.net> wrote:
>>>>>>>>
>>>>>>>> On 24/06/2021 08:45, Zhenyu Wu wrote:
>>>>>>>>> Thanks! this is some information of some programs.
>>>>>>>>> ```
>>>>>>>>> # boot from liveUSB
>>>>>>>>> $ btrfs check /dev/sda2
>>>>>>>>> [1/7] checking root items
>>>>>>>>> [2/7] checking extents
>>>>>>>>> [3/7] checking free space cache
>>>>>>>>> [4/7] checking fs roots
>>>>>>>>> [5/7] checking only csums items (without verifying data)
>>>>>>>>> [6/7] checking root refs
>>>>>>>>> [7/7] checking quota groups
>>>>>>>>> # after mount /dev/sda2 to /mnt/gentoo
>>>>>>>>
>>>>>>>> Did you do 'mount -o subvolid=5 /dev/sda2 /mnt/gentoo' to 
>>>>>>>> make sure you
>>>>>>>> can see all subvolumes, not just the default subvolume? I 
>>>>>>>> guess it
>>>>>>>> doesn't matter for quota, but it matters if you are using 
>>>>>>>> tools like du.
>>>>>>>>
>>>>>>>> You don't even need to use a liveUSB. On your normal 
>>>>>>>> mounted system you
>>>>>>>> can do...
>>>>>>>>
>>>>>>>> mkdir /tmp/fulldisk
>>>>>>>> mount -o subvolid=5 /dev/sda2 /tmp/fulldisk
>>>>>>>> ls -lA /tmp/fulldisk
>>>>>>>>
>>>>>>>> to see if there are other subvolumes which are not 
>>>>>>>> visible in /

  reply	other threads:[~2021-06-24 23:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 13:02 [question] free space of disk with btrfs is too different from other du 吴振宇
2021-06-22 14:31 ` Su Yue
     [not found]   ` <CAJ9tZB9M=KOWVLH_azagtBnxDzpV2=ssnBcYsJx6Ao8cQOELhg@mail.gmail.com>
     [not found]     ` <5yy5orgi.fsf@damenly.su>
2021-06-23 11:46       ` 吴振宇
2021-06-23 12:00         ` Qu Wenruo
2021-06-23 12:08           ` Qu Wenruo
2021-06-24  7:45             ` Zhenyu Wu
2021-06-24  7:54               ` Qu Wenruo
2021-06-24  8:32               ` Graham Cobb
2021-06-24  9:52                 ` Zhenyu Wu
2021-06-24 10:07                   ` Qu Wenruo
2021-06-24 11:33                     ` Zhenyu Wu
2021-06-24 12:30                       ` Qu Wenruo
2021-06-24 14:38                         ` Zhenyu Wu
2021-06-24 14:52                           ` Zhenyu Wu
2021-06-24 23:33                             ` Qu Wenruo
2021-06-24 23:51                               ` Su Yue [this message]
2021-06-24 23:46                           ` Qu Wenruo
2021-06-25  0:59                             ` Qu Wenruo
2021-06-25  5:28                               ` Qu Wenruo
2021-06-25  5:36                                 ` Qu Wenruo
2021-06-26  7:17                                   ` Zhenyu Wu
2021-06-26  8:05                                     ` Qu Wenruo
2021-06-26  8:17                                       ` Zhenyu Wu
2021-06-25  5:30                               ` Zhenyu Wu

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=wnqiom4e.fsf@damenly.su \
    --to=l@damenly.su \
    --cc=g.btrfs@cobb.uk.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wuzy001@gmail.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