All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Zhenyu Wu <wuzy001@gmail.com>, Graham Cobb <g.btrfs@cobb.uk.net>
Cc: Su Yue <l@damenly.su>, linux-btrfs@vger.kernel.org
Subject: Re: [question] free space of disk with btrfs is too different from other du
Date: Thu, 24 Jun 2021 18:07:08 +0800	[thread overview]
Message-ID: <93bc4428-467f-9a08-0dbf-1fae8cec42dd@gmx.com> (raw)
In-Reply-To: <CAJ9tZB-7ogKcPCF=r72jJ3pvZLD3h6VfQbks-pfkB5N_yhJzTg@mail.gmail.com>



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 10:07 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 [this message]
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
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=93bc4428-467f-9a08-0dbf-1fae8cec42dd@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=g.btrfs@cobb.uk.net \
    --cc=l@damenly.su \
    --cc=linux-btrfs@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.