All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: paused balance convert from raid1 can no longer be a writeable mount
Date: Wed, 4 Feb 2015 21:38:35 -0500	[thread overview]
Message-ID: <20150205023835.GA23108@hungrycats.org> (raw)
In-Reply-To: <CAJCQCtQUrfYhiG_Huv+M5w=6bEsvgnY1kUbreO-dANMhCrALbQ@mail.gmail.com>

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

On Wed, Feb 04, 2015 at 01:53:09PM -0700, Chris Murphy wrote:
> This is completely reproducible with a brand new file system created
> as raid1, using kernel 3.19 and btrfs-progs 3.18.

I think you'll find it's reproducible with any kernel after 3.8-rc1
(circa October 2012).

> The conversion from raid1 to single, if paused, will apparently break
> the file system's ability to be subsequently mounted writable. 

Only if you remove a disk (or one fails).

> And
> further, btrfs-image fails. I've updated the bug report.
> https://bugzilla.kernel.org/show_bug.cgi?id=92641
> 
> First, the conversion from data/metadata raid1 should be faster than
> requiring fully reading and writing the file system. As this is a 2
> device raid1, each is already effectively data/metadata single, so I'm
> not sure why anything other than metadata needs rewriting.
> 
> Second, either what I'm doing should be disallowed (user can't force
> conversion of a degraded array to single), or the file system
> shouldn't break like this.
> 
> Third, the error message is confusing "too many missing devices,
> writeable mount is not allowed" the first part of that is definitely
> not true. How can there be too many missing devices when it started
> out as a 2 device volume and the remaining device isn't an ro or seed
> device?

I'd point out bug #60594, but it seems you've already been there.
I bumped into the same bug myself.

The problem is that one is more than the maximum number of missing devices
for the single profile, and you are missing one disk, so the filesystem
gives up.  It doesn't check that all the single chunks are on currently
present disks.

If you revert commit 292fd7fc39aa06668f3a8db546714e727120cb3e
you might be able to finish the balance and resume non-degraded read-write
operation.

> Chris Murphy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

  reply	other threads:[~2015-02-05  2:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04  7:02 paused balance convert from raid1 can no longer be a writeable mount Chris Murphy
2015-02-04 20:53 ` Chris Murphy
2015-02-05  2:38   ` Zygo Blaxell [this message]
2015-02-05  3:00     ` Chris Murphy

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=20150205023835.GA23108@hungrycats.org \
    --to=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.