linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Anton Shepelev <anton.txt@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Interpreting `btrfs filesystem show'
Date: Mon, 15 Oct 2018 11:02:31 -0400	[thread overview]
Message-ID: <6f37f89d-105e-1abe-980a-3c0662c98c4f@gmail.com> (raw)
In-Reply-To: <20181015174238.cb240bc0df3efffb92cec42a@gmail.com>

On 2018-10-15 10:42, Anton Shepelev wrote:
> Hugo Mills to Anton Shepelev:
> 
>>> While trying to resolve free space problems, and found
>>> that I cannot interpret the output of:
>>>
>>>> btrfs filesystem show
>>>
>>> Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
>>>         Total devices 1 FS bytes used 34.06GiB
>>>         devid    1 size 40.00GiB used 37.82GiB path /dev/sda2
>>>
>>> How come the total used value is less than the value
>>> listed for the only device?
>>
>>    "Used" on the device is the mount of space allocated.
>> "Used" on the FS is the total amount of actual data and
>> metadata in that allocation.
>>
>>    You will also need to look at the output of "btrfs fi
>> df" to see the breakdown of the 37.82 GiB into data,
>> metadata and currently unused.
>>
>> See
>> https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools for the details
> 
> Thank you, Hugo, understood.  mount/amount is a very fitting
> typo :-)
> 
> Does the standard `du' tool work correctly for btfrfs?
> 
For the default 'physical usage' mode, it functionally does not work 
correctly, because it does not know about reflinks.  The easiest way to 
see this is to create a couple of snapshots of a subvolume alongside the 
subvolume, and then run `du -s --totals` on those snapshots and the 
subvolume.  It will report the total space usage to be equal to the sum 
of the values reported for each snapshot and the subvolume, when it 
should instead only count the space usage for shared data once.

For the 'apparent usage' mode provided by the GNU implementation, it 
does work correctly.

  reply	other threads:[~2018-10-15 15:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15 14:24 Interpreting `btrfs filesystem show' Anton Shepelev
2018-10-15 14:26 ` Hugo Mills
2018-10-15 14:30   ` Hugo Mills
     [not found]   ` <20181015174040.6f4962336386d8549026908c@gmail.com>
2018-10-15 14:42     ` Anton Shepelev
2018-10-15 15:02       ` Austin S. Hemmelgarn [this message]
2018-10-15 15:48   ` Martin Steigerwald

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=6f37f89d-105e-1abe-980a-3c0662c98c4f@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=anton.txt@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).