From: Marc Lehmann <schmorp@schmorp.de>
To: Remi Gauvin <remi@georgianit.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs dev del not transaction protected?
Date: Fri, 20 Dec 2019 18:50:17 +0100 [thread overview]
Message-ID: <20191220175017.GA6387@schmorp.de> (raw)
In-Reply-To: <45b11982-0847-8e2c-b40f-0c22ed21de2b@georgianit.com>
On Fri, Dec 20, 2019 at 12:24:05PM -0500, Remi Gauvin <remi@georgianit.com> wrote:
> You don't need hints, the problem is right here.
Yes, I already guessed that (see my other mail). I fortunately can add two
more devices. However:
> device left with unallocated space, so no new metadata space can be
> allocated until you fix that.
I think it really shouldn't be up to me to second guess btrfs's not very
helpful error messages "and fix things". And if I couldn't add another
device, I would be pretty much fucked - btrfs balance does not allow me
to move any chunks to the other device, I tried balancing 10 data chunks
and 10 metadata chunks - the data chunks balanced successfully but nothing
changed, and the metadata chunks instantly hit the ENOSPC problem.
Pushing "fix things" at users without giving them the ability to do so is
rather poor.
So is there a legit fix for this? The tools don't allow me to rebalance
the filesystem so there is more space on the drives and deleting data and
writing it again doesn't seem to help - btrfs still wants to write to the
nearly full disks. I could probably convert the metadata to single and
back, but as long as btrfs has no way orf moving data form one disk to
another, that's going to be tough. Maybe converting to single and resizing
would do the trick - seriously, though, btrfs shouldn't force users to
jump through such hoops.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
next prev parent reply other threads:[~2019-12-20 17:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 4:05 btrfs dev del not transaction protected? Marc Lehmann
2019-12-20 5:24 ` Qu Wenruo
2019-12-20 6:37 ` Marc Lehmann
2019-12-20 7:10 ` Qu Wenruo
2019-12-20 13:27 ` Marc Lehmann
2019-12-20 13:41 ` Qu Wenruo
2019-12-20 16:53 ` Marc Lehmann
2019-12-20 17:24 ` Remi Gauvin
2019-12-20 17:50 ` Marc Lehmann [this message]
2019-12-20 18:00 ` Marc Lehmann
2019-12-20 18:28 ` Eli V
2019-12-20 20:24 ` Chris Murphy
2019-12-20 23:30 ` Marc Lehmann
2019-12-21 20:06 ` Zygo Blaxell
2019-12-21 1:32 ` Qu Wenruo
2019-12-20 17:07 ` Marc Lehmann
2019-12-21 1:23 ` Qu Wenruo
2019-12-20 17:20 ` Marc Lehmann
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=20191220175017.GA6387@schmorp.de \
--to=schmorp@schmorp.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=remi@georgianit.com \
/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