All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonah Sabean <me@jse.io>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Replacing disk strange (buggy?) behaviour - RAID1
Date: Tue, 20 Apr 2021 21:23:39 -0300	[thread overview]
Message-ID: <CAFMvigfQ+XotjO_578LvSvycD3sbLcV_AP6A+B0U+ybApU2zGA@mail.gmail.com> (raw)
In-Reply-To: <9bdb8872-3394-534f-a9e3-11dcc5ea2819@gmail.com>

Thanks for the reply, it's appreciated!

> Mounting raid1 btrfs writable in degraded mode creates chunks with
> single profile. This is long standing issue. What is rather surprising
> that you apparently have chunk size 819GiB which is suspiciously close
> to 10% of 8TiB. btrfs indeed limits chunk size to 10% of total space,
> but it should not exceed 10GiB. Could it be specific Ubuntu issue?
>
> So when you wrote data in degraded mode it had to allocate new chunk
> with "single" profile.

That's strange as I didn't write actual data to the disk during that
time. Perhaps Ubuntu wrote some hidden file or something to it, I have
no idea, but I didn't interact with the filesystem beyond doing the
replace after mounting it. Still... 10% of 8TiB may be what's
happening and if so that's really strange... and massive. I'd don't
think it was a single chunk equal to 10% though, as when I converted
it to raid1, I specified the soft filter with `-dconvert=raid1,soft`,
and the resulting output once it was complete was:

Done, had to relocate 825 out of 1648 chunks

So the hypothesis that it was one large chunk doesn't make hold up to
me knowing that output. I thus assume the chunks were all 1GiB given
that many. Unfortunately I didn't save the output of the balance with
`-dusage=0`, but I do recall it being in the 800s as well.

> > Why didn't it free
> > those up as it replaced the missing disk and duplicated the data in
> > RAID1?
>
> Device replacement restored mirrored data (chunks with "raid1" profile)
> on the new device. It had no reasons to touch chunks with "single"
> profile because from btrfs point of view these chunks never had any data
> on replaced device so there is nothing to write there.
>
> > Shouldn't it all be RAID1 once it's complete,
> No. btrfs replace restores content of missing device. It is not
> replacement for profile conversion.

Makes sense, knowing that I would expect that. I just have no idea why
it allocated 800GiB, especially since I didn't write anything to the
single disk during the convert process, much less ~800GiB.

> > Everything was RAID1 all up until the disk replacement, so it clearly
> > did this during the `btrfs replace` process.
>
> No, it did it during degraded writable mount.
>
> > Did I do this wrong, or
> > is there a bug?
>
> There is misfeature that btrfs creates "single" chunks during degraded
> mount. Ideally it should create degraded raid1 chunks.

Hmm... would be nice to see this then. Is there a patch for it,
assuming it's planned?

Thanks,
-Jonah

  reply	other threads:[~2021-04-21  0:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 15:22 Replacing disk strange (buggy?) behaviour - RAID1 Jonah Sabean
2021-04-20 18:19 ` Andrei Borzenkov
2021-04-21  0:23   ` Jonah Sabean [this message]
2021-04-21  8:39     ` Forza

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=CAFMvigfQ+XotjO_578LvSvycD3sbLcV_AP6A+B0U+ybApU2zGA@mail.gmail.com \
    --to=me@jse.io \
    --cc=arvidjaar@gmail.com \
    --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 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.