Chris Murphy posted on Sun, 16 Feb 2014 12:54:44 -0700 as excerpted: > On Feb 16, 2014, at 12:18 PM, Hendrik Friedel <hend...@friedels.name> > wrote:
[On balance converting to single from raidN:] >> I think it didn't work. >> >> btrfs balance start -dconvert=single -mconvert=single -sconvert=single >> --force /mnt/BTRFS/Video/ >> After >10h: >> btrfs balance status /mnt/BTRFS/Video/ >> No balance found on '/mnt/BTRFS/Video/' >> root@homeserver:~# btrfs fi df /mnt/BTRFS/Video/ >> Data, RAID0: total=4.00GB, used=4.00GB >> Data: total=2.29TB, used=2.29TB >> System: total=32.00MB, used=256.00KB >> Metadata: total=4.00GB, used=2.57GB > > It looks like everything is single except for 4GB of data which is still > raid0. Weird. There should be a bunch of messages in dmesg during a > normal/successful balance, and either something mentioned or missing > might provide a clue why some chunks weren't converted. Agreed. > Unmounted, what do you get for btrfs check? Agreed, but it's worth an explanation and explicit warning just in case... btrfs check is read-only by default -- it'll tell you what it thinks is wrong, but won't attempt to correct anything. Adding --repair tells it to try to correct the errors it found, but the recommendation is do NOT use --repair unless it's a last-ditch effort after other things failed, and preferably only after a btrfs dev says to, because sometimes it can make things worse instead of better. So running the (read-only) /check/ to see what it says is a good idea, but do NOT try to run it with --repair just yet, no matter what errors it thinks it sees. >> Do you have an idea what could be wrong? > > No. I'd say it's a bug. 3.14rc3 should be out today, and might be worth > a shot. Or btrfs-next. If you try again, you only need to convert the > data profile. https://btrfs.wiki.kernel.org/index.php/Balance_Filters Based on that, I'd suggest btrfs balance start -dconvert=single,soft /mnt/BTRFS/Video/ Given that there's only 4 GiB left to convert, it should go MUCH faster than the 10 hours the multiple TiB took. > Also, 10 hours to balance two disks at 2.3TB seems like a long time. I'm > not sure if that's expected. FWIW, I think you may not realize how big 2.3 TiB is, and/or how slow spinning rust can be when dealing with TiBs of potentially fragmented data... 2.3TiB * 1024GiB/TiB * 1024 MiB/GiB / 10 hours / 60 min/hr / 60 sec/min = 66.99... real close to 67 MiB/sec Since it's multiple TiB we're talking and only two devices, that's almost certainly spinning rust, not SSD, and on spinning rust, 67 MiB/sec really isn't /that/ bad, especially if the filesystem wasn't new and had been reasonably used, thus likely had some fragmentation to deal with. But the good news is that the 4 GiB remaining should be much faster; @ the 67 MiB/sec average of the above, we're talking about a minute. Throwing in that "soft" should tell it to ignore the previously converted data, and only balance data chunks that aren't yet in the target single profile, so it should only do the 4 GiB that's still raid0, not redo the multiple TiB. Tho it will probably have to check the profile on each chunk still, and if that remaining data is hugely fragmented or something that could take a bit longer, so it could be two minutes or ten minutes instead of one, but if it's more than an hour, I'd definitely be wondering what's up! -- 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
