linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: understanding disk space usage
Date: Thu, 9 Feb 2017 12:53:56 -0500	[thread overview]
Message-ID: <d208b9d4-4e82-f6bc-109a-aca8951495cf@gmail.com> (raw)
In-Reply-To: <20170209132504.ukjehzba5w7k42ow@angband.pl>

On 2017-02-09 08:25, Adam Borowski wrote:
> On Wed, Feb 08, 2017 at 11:48:04AM +0800, Qu Wenruo wrote:
>> Just don't believe the vanilla df output for btrfs.
>>
>> For btrfs, unlike other fs like ext4/xfs, which allocates chunk dynamically
>> and has different metadata/data profile, we can only get a clear view of the
>> fs from both chunk level(allocated/unallocated) and extent
>> level(total/used).
>
> Actually, df lies on ext4 too.  sysvfs-derived filesystems have statically
> allocated inodes, which means that if you try to store small files, at some
> point you'll run out of space despite df claiming you have plenty left.
Which is why the `-i` option for df exists.

That said, not having any more space is not the same as not being able 
to create more files, and that's been the case since long before Linux 
even existed.  Most people don't think about this though because ext4 
and most other filesystems that use static inode tables allocate insane 
numbers of inodes at mkfs time so it (usually) doesn't ever become an issue.


      reply	other threads:[~2017-02-09 17:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 16:44 understanding disk space usage Vasco Visser
2017-02-08  3:48 ` Qu Wenruo
2017-02-08  9:55   ` Vasco Visser
2017-02-09  2:53     ` Qu Wenruo
2017-02-09 12:01       ` Vasco Visser
2017-02-08 14:46   ` Peter Grandi
2017-02-08 17:50     ` Austin S. Hemmelgarn
2017-02-08 21:45       ` Peter Grandi
2017-02-09 12:47         ` Austin S. Hemmelgarn
2017-02-08 18:03     ` Hugo Mills
2017-02-09 13:25   ` Adam Borowski
2017-02-09 17:53     ` Austin S. Hemmelgarn [this message]

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=d208b9d4-4e82-f6bc-109a-aca8951495cf@gmail.com \
    --to=ahferroin7@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).