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 /
next prev parent 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