From: Sean Greenslade <sean@seangreenslade.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: RAID1 disk upgrade method
Date: Thu, 28 Jan 2016 10:37:56 -0500 [thread overview]
Message-ID: <20160128153756.GA19617@fox.rh.rit.edu> (raw)
In-Reply-To: <56AA0A0A.1060807@gmail.com>
On Thu, Jan 28, 2016 at 07:31:06AM -0500, Austin S. Hemmelgarn wrote:
> >Got the opportunity to reboot, and things appear to be OK. Still, I
> >would expect replace to work without requiring a reboot, so this may
> >still be a bug. I'm running a scrub to verify things, and once that
> >completes I'll do the second replace and see if I encounter the same
> >problem.
>
> That is unusual, it's supposed to work without needing a reboot or rescan,
> so I think you may have found a bug.
Did the second replace, and encountered a slightly different issue.
Btrfs fi show did list both new devices after the replace completed,
however the partition was no longer mounted. Trying to mount, the mount
command returned 0 but the partition was not actually mounted. I got
this in dmesg:
[Thu Jan 28 10:20:20 2016] BTRFS info (device sdd1): disk space caching
is enabled
[Thu Jan 28 10:20:20 2016] BTRFS: has skinny extents
[Thu Jan 28 10:20:20 2016] BTRFS: bdev /dev/sda1 errs: wr 0, rd 186,
flush 0, corrupt 0, gen 0
I ejected and re-inserted the HDDs, and everything was happy again. The
mount actually succeeded, with the same dmesg output. If I had to guess,
I'd say there's probably some stale state left over in the kernel after
the replace. I may try to create a test case to reproduce this later if
I have time.
Additionally, the filesystem did not expand to the larger drives after
the replace. So I ran btrfs fi resize max, and I got the following:
Label: none uuid: 573863ec-d55e-4817-8c11-70bb8523b643
Total devices 2 FS bytes used 1.64TiB
devid 1 size 2.73TiB used 1.71TiB path /dev/sdb1
devid 2 size 1.82TiB used 1.71TiB path /dev/sda1
[Thu Jan 28 10:32:36 2016] BTRFS: new size for /dev/sdb1 is 3000591912960
It only resized one of the two devices, and I'm suspicious because the
one that didn't resize is also the one that reports read errors in the
mount dmesg output.
Any ideas on what to try next? I'm kicking off a scrub for now.
--Sean
next prev parent reply other threads:[~2016-01-28 15:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 3:45 RAID1 disk upgrade method Sean Greenslade
2016-01-22 4:37 ` Chris Murphy
2016-01-22 10:54 ` Duncan
2016-01-23 21:41 ` Sean Greenslade
2016-01-24 0:03 ` Chris Murphy
2016-01-27 22:45 ` Sean Greenslade
2016-01-27 23:55 ` Sean Greenslade
2016-01-28 12:31 ` Austin S. Hemmelgarn
2016-01-28 15:37 ` Sean Greenslade [this message]
2016-01-28 16:18 ` Chris Murphy
2016-01-28 18:47 ` Sean Greenslade
2016-01-28 19:37 ` Austin S. Hemmelgarn
2016-01-28 19:46 ` Chris Murphy
2016-01-28 19:49 ` Austin S. Hemmelgarn
2016-01-28 20:24 ` Chris Murphy
2016-01-28 20:41 ` Sean Greenslade
2016-01-28 20:44 ` Austin S. Hemmelgarn
2016-01-28 23:01 ` Chris Murphy
2016-01-29 12:14 ` Austin S. Hemmelgarn
2016-01-29 20:27 ` Henk Slager
2016-01-29 20:40 ` Austin S. Hemmelgarn
2016-01-29 22:06 ` Henk Slager
2016-02-01 12:08 ` Austin S. Hemmelgarn
2016-01-29 20:41 ` Chris Murphy
2016-01-30 14:50 ` Patrik Lundquist
2016-01-30 19:44 ` Chris Murphy
2016-02-04 19:20 ` Patrik Lundquist
2016-01-28 19:39 ` Chris Murphy
2016-01-28 22:51 ` Duncan
2016-02-14 0:44 ` Sean Greenslade
2016-01-22 14:27 ` Austin S. Hemmelgarn
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=20160128153756.GA19617@fox.rh.rit.edu \
--to=sean@seangreenslade.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.