boli posted on Thu, 16 Jun 2016 20:18:50 +0200 as excerpted: > This second replace is now finished, and it looks OK now: > > # btrfs replace status /data > Started on 16.Jun 01:15:17, finished on 16.Jun 11:40:30, > 0 write errs, 0 uncorr. read errs
> However, while the replace was in progress, it showed weird stuff, > like this percentage > 100 today at 9am (~3 hours before completion): > > # btrfs replace status /data > 272.1% done, 0 write errs, 0 uncorr. read errs > > Also, contrary to he first replace, filesystem info was not updated > during the replace > I'm happy it worked, just wondering why it behaved > weirdly this second time. > > During the first replace, my Fedora 23 was booted in emergency mode, > whereas for the second time it was booted normally. > > I'm going to reboot now to update Kernel 4.5.5 to 4.5.6 > and then continue replacing drives. I'm guessing you were either running differing kernels, or it had something to do with the information available... /sys and /proc mounted, udev and lvm/device-mapper possibly in different states due to the differing systemd target states, possibly different btrfs, udev and lvm/dm versions in initr* vs the main system, etc. In particular, I know there have been some patches to fix problems where it would count only one device, generally the one it was mounted with, as 100%, when the balance affected multiple devices, so it could get to multiple-hundred percent done. And there have been patches having to do with resolving names to the canonical form, vs the various symlinked udev/lvm/mdraid/etc names. But I wouldn't be surprised if there's still inconsistencies, particularly related to udev/lvm state differences that may well appear between systemd emergency and multi-user target modes or between initr* and main system boot, especially if the initr* is running differing versions of one or more affected utilities. So if it was the same kernel version, it's likely that in the one case it simply wasn't mapping the full filesystem for the purpose of calculating percentages and current filesystem numbers, correctly. That should be corrected in time, and Fedora is likely to see it pretty early compared to everyone else given the number of upstream devs that package for it and sometimes pre-release or first release deployment versions with systemd/udev/lvm patches that others simply don't have yet, but it could yet be a few years before it /fully/ settles down. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
