Re: ENOSPC errors during balance

[Duncan <1i5t5.duncan@cox.net>]

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 <marcec@gmx.de>:
> 
>> Am Sun, 20 Jul 2014 12:22:33 +0200 schrieb Marc Joliet <marcec@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