public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Marcus Sundman <sundman@iki.fi>
Cc: linux-btrfs@vger.kernel.org, Josef Bacik <jbacik@fb.com>,
	Jim Salter <jim@jrs-s.net>
Subject: Re: No space left on device (again)
Date: Thu, 27 Feb 2014 07:48:57 +0000	[thread overview]
Message-ID: <20140227074857.GD13899@carfax.org.uk> (raw)
In-Reply-To: <530E83C7.5080101@iki.fi>

[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]

On Thu, Feb 27, 2014 at 02:16:07AM +0200, Marcus Sundman wrote:
> On 25.02.2014 22:30, Josef Bacik wrote:
> >On 02/25/2014 03:27 PM, Marcus Sundman wrote:
> >>On 25.02.2014 22:19, Hugo Mills wrote:
> >>>On Tue, Feb 25, 2014 at 01:05:51PM -0500, Jim Salter wrote:
> >>>>370GB of 410GB used isn't really "fine", it's over 90% usage.
> >>>>
> >>>>That said, I'd be interested to know why btrfs fi show
> >>>>/dev/sda3 shows 412.54G used, but btrfs fi df /home shows 379G
> >>>>used...
> >>>This is an FAQ...
> >>>
> >>>btrfs fi show tells you how much is allocated out of the
> >>>available pool on each disk. btrfs fi df then shows how much of
> >>>that allocated space (in each category) is used.
> >>What is the difference between the "used 371.11GB" and the "used
> >>412.54GB" displayed by "btrfs fi show"?
> >>
> >>>The problem here is also in the FAQ: the metadata is close to
> >>>full -- typically something like 500-750 MiB of headroom is
> >>>needed in metadata. The FS can't allocate more metadata because
> >>>it's allocated everything already (total=used in btrfs fi show),
> >>>so the solution is to do a filtered balance:
> >>>
> >>>btrfs balance start -dusage=5 /mountpoint
> >>Of course that was the first thing I tried, and it didn't help *at*
> >>*all*:
> >>
> >The -dusage=<number> is a means to an end, so if that doesn't work try
> >a larger number, up to 100.  Really once you pass 50 and it's not
> >working then it's time to just do a balance.  The next thing is to use
> >compression (too late for this option really) or add another disk.
> 
> So it relocates some chunks. What will that do? Does it mean I can
> now use the remaining 45 GB? Or will it run out of "disk space"
> again after using a gig or two?

   What it's done is moved some of the data around. One effect of this
process is that when a balance operation balances a chunk, it
deallocates that space. Therefore you should now see that the "used"
value for the device in btrfs fi show is lower than the "total" value.
Also, the "total" value for data in btrfs fi df should now be lower
than it was before.

   This means that the next time the FS needs some metadata space
(probably real soon now, because it was running out of it earlier), it
now has uncommitted space to allocate to metadata.

> If it's the allocated metadata space that is the problem then how
> can I pre-allocate more of it so it won't run out of it?

   It's possible that when filling up the remaining 45 GiB of space
the metadata will need to expand again, and you will need to run a
balance to do the same job again. Unless you have lots and lots of
small files or small fragments (or lots more snapshots than you've
been making to date), I'd say it's probably unlikely, though.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
        --- Well, sir, the floor is yours.  But remember, the ---        
                              roof is ours!                              

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  parent reply	other threads:[~2014-02-27  7:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 16:49 No space left on device (again) Marcus Sundman
2014-02-25 18:05 ` Jim Salter
2014-02-25 19:59   ` Marcus Sundman
2014-02-25 20:19   ` Hugo Mills
2014-02-25 20:27     ` Marcus Sundman
2014-02-25 20:30       ` Josef Bacik
2014-02-26 10:38         ` Sander
2014-02-27  0:16         ` Marcus Sundman
2014-02-27  1:17           ` Josef Bacik
2014-02-27  7:48           ` Hugo Mills [this message]
2014-02-25 20:30       ` cwillu
2014-02-25 20:40       ` Hugo Mills

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=20140227074857.GD13899@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=jbacik@fb.com \
    --cc=jim@jrs-s.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sundman@iki.fi \
    /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