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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
