From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: ojab // <ojab@ojab.ru>
Cc: Henk Slager <eye1tm@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Cannot balance FS (No space left on device)
Date: Sat, 11 Jun 2016 00:39:20 +0200 [thread overview]
Message-ID: <575B4198.4050803@mendix.com> (raw)
In-Reply-To: <CAKzrAgTSnSyNV7KO4ERkH1BohdPEzzwbqGVSx3UhET+5PwUH2g@mail.gmail.com>
On 06/11/2016 12:10 AM, ojab // wrote:
> On Fri, Jun 10, 2016 at 9:56 PM, Hans van Kranenburg
> <hans.van.kranenburg@mendix.com> wrote:
>> You can work around it by either adding two disks (like Henk said), or by
>> temporarily converting some chunks to single. Just enough to get some free
>> space on the first two disks to get a balance going that can fill the third
>> one. You don't have to convert all of your data or metadata to single!
>>
>> Something like:
>>
>> btrfs balance start -v -dconvert=single,limit=10 /mnt/xxx/
>
> Unfortunately it fails even if I set limit=1:
>> $ sudo btrfs balance start -v -dconvert=single,limit=1 /mnt/xxx/
>> Dumping filters: flags 0x1, state 0x0, force is off
>> DATA (flags 0x120): converting, target=281474976710656, soft is off, limit=1
>> ERROR: error during balancing '/mnt/xxx/': No space left on device
>> There may be more info in syslog - try dmesg | tail
Ah, apparently the balance operation *always* wants to allocate some new
empty space before starting to look more close at the task you give it...
This means that it's trying to allocate a new set of RAID0 chunks
first... and that's exactly the opposite of what we want to accomplish here.
If you really can add only one extra device now, there's always a more
dirty way to get the job done.
What you can do for example is:
- partition the new disk in two partitions
- add them both to the filesystem (btrfs doesn't know both block devices
are on the same physical disk, ghehe)
- convert a small number of data blocks to single
- then device delete the third disk again so the single chunks move back
to the two first disks
- add the third disk back as one whole block device
- etc...
:D
Moo,
--
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com
next prev parent reply other threads:[~2016-06-10 22:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 18:04 Cannot balance FS (No space left on device) ojab //
2016-06-10 21:00 ` Henk Slager
2016-06-10 21:33 ` ojab //
2016-06-10 21:56 ` Hans van Kranenburg
2016-06-10 22:10 ` ojab //
2016-06-10 22:39 ` Hans van Kranenburg [this message]
2016-06-13 12:33 ` Austin S. Hemmelgarn
2016-07-02 15:07 ` Hans van Kranenburg
2016-07-02 19:03 ` Chris Murphy
2016-07-04 8:32 ` ojab //
2016-06-12 22:00 ` ojab //
[not found] <CAKzrAgSGRQk_wEairoCUhK6GDCFOVbVWJLub4M_fu7uHC-pO0w@mail.gmail.com>
2016-06-15 10:59 ` ojab //
2016-06-15 12:41 ` E V
2016-06-15 19:29 ` ojab //
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=575B4198.4050803@mendix.com \
--to=hans.van.kranenburg@mendix.com \
--cc=eye1tm@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=ojab@ojab.ru \
/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