linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Error During Balancing - No Space Left on Device
Date: Wed, 1 Nov 2017 19:45:52 +0000 (UTC)	[thread overview]
Message-ID: <pan$44703$f2eabaf1$fdaf8636$ed495365@cox.net> (raw)
In-Reply-To: 8E856F12-DA15-4396-8B5D-B2609D1461BE@networkinsanity.com

Ben Hooper posted on Wed, 01 Nov 2017 16:18:25 +0000 as excerpted:

> Hello,
> 
> I am trying to upgrade capacity on by btrfs filesystem by replacing
> smaller disks with larger ones. I added 2x8TB drives to the existing
> RAID10 but am not seeing the expected increase in space and am
> experiencing enospc errors during balance. This array has been extended
> several times but this is the first time I have seen any issues.
> 
> Looking at the list archives, it seems that some others have had similar
> problems. Has anyone found a solution or any recommendations?


> # btrfs balance start -v -dusage=0 /data
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=0
> ERROR: error during balancing '/data': No space left on device
> There may be more info in syslog - try dmesg | tail

 
> # uname -a
> Linux nas 4.13.9-1.el7.elrepo.x86_64 #1 SMP
> Sun Oct 22 10:02:34 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

There's a known bug with kernel 4.13 with balance on TB+ sized 
filesystems.  A reserve-space calculation goes haywire and attempts to 
reserve orders of magnitude more space than it actually needs, and given 
that PB-sized storage isn't particularly common yet, more space than it 
actually has, as well.  (Not that PB would fix it, the problem seems to 
be one of scale, hundred-GB sized filesystems don't seem to be as badly 
affected, so PB-sized filesystems may actually make the bug worse and 
it'd think it needed EB-sized!)

Try waiting for 4.14 if it's not urgent, or try the latest 4.14-rc or 
downgrade to, say the latest LTS series 4.9.x kernel, and try the balance 
again.  In theory 4.13 stable series should get the fix as well, but in 
practice, not being an LTS, as late in the 4.14 cycle as it is already, 
I'm not sure whether the fix will make it to 4.13 before it goes 
unsupported, or not.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2017-11-01 19:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 16:18 Error During Balancing - No Space Left on Device Ben Hooper
2017-11-01 19:45 ` Duncan [this message]
2017-11-02 15:56 ` Ben Hooper
2017-11-07 23:01   ` Ben Hooper

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='pan$44703$f2eabaf1$fdaf8636$ed495365@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).