Marc Joliet posted on Sun, 20 Jul 2014 21:44:40 +0200 as excerpted: > Am Sun, 20 Jul 2014 13:40:54 +0200 schrieb Marc Joliet <mar...@gmx.de>: > >> Am Sun, 20 Jul 2014 12:22:33 +0200 schrieb Marc Joliet <mar...@gmx.de>: >> >> [...] >> > I'll try this and see, but I think I have more files >1GB than would >> > account for this error (which comes towards the end of the balance >> > when only a few chunks are left). I'll see what "find /mnt -type f >> > -size +1G" finds :) .
Note that it's extent's over 1 GiB on the converted former ext4, not necessarily files over 1 GiB. You may have files over a GiB that were already broken into extents that are all less than a GiB, and btrfs would be able to deal with them fine. It's only when a single extent ended up larger than a GiB on the former ext4 that btrfs can't deal with it. >> Now that I think about it, though, it sounds like it could explain the >> sudden surge in total data size: for one very big file, several >> chunks/extents are created, but the data cannot be copied from the >> original ext4 extent. I hadn't thought about that effect, but good deductive reasoning. =:^) > Well, turns out that was it! > > What I did: > > - delete the single largest file on the file system, a 12 GB VM image, > along with all subvolumes that contained it > - rsync it over again - start a full balance > > This time, the balance finished successfully :-) . Good to read! We're now two for two on this technique working around this problem! =:^) -- 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
