Re: 3.18.0: kernel BUG at fs/btrfs/relocation.c:242!

[Robert White <rwhite@pobox.com>]

On 12/13/2014 12:16 AM, Tomasz Chmielewski wrote:
> On 2014-12-12 23:58, Robert White wrote:
>
>> I don't have the history to answer this definitively, but I don't
>> think you have a choice. Nothing else is going to touch that error.
>>
>> I have not seen any "oh my god, btrfsck just ate my filesystem errors"
>> since I joined the list -- but I am a relative newcomer.
>>
>> I know that you, of course, as a contentious and well-traveled system
>> administrator, already have a current backup since you are doing
>> storage maintenance... right? 8-)
>
> Who needs backups with btrfs, right? :)
>
> So apparently btrfsck --repair fixed some issues, the fs is still
> mountable and looks fine.
>
> Running balance again, but that will take many days there.

Might I ask why you are running balance? After a persistent error I'd 
understand going straight to scrub, but balance is usually for 
transformation or to redistribute things after atypical use.

An entire generation of folks have grown used to defraging windows boxes 
and all, but if you've already got an array that is going to take "many 
days" to balance what benefit do you actually expect to receive?


Defrag -- used for "I think I'm getting a lot of unnecessary head seek 
in this application, these files need to be brought into closer order".

Scrub -- used for defensive checking a-la checkdisk. "I suspect that 
after that unexpected power outage something may be a little off", or 
alternately "I think my disks are giving me bitrot, I better check".

Btrfsck -- used for "I suspect structural problems caused by real world 
events like power hits or that one time when the cat knocked over my 
tower case while I was vacuuming all my sql tables." (often reserved for 
"hey, I'm getting weird messages from the kernel about things in my 
filesystem".)

Balance -- primary -- used for "Well I used to use this filessytem for a 
small number of large files, but now I am processing a large number of 
small files and I'm running out of metadata even though I've got a lot 
of space." (or vice versa)

Balance -- other -- used for "I just changed the geometry of my 
filessytem by adding or removing a disk and I want to spread out.

Balance -- (conversion/restructuring) -- used for "single is okay, but 
I'd rather raid-0 to spread out my load across these many disks" or 
"gee, I'd like some redundancy now that I have the room.



Frequent balancing of a Copy On Write filesystem will tend to make 
things somewhat anti-optimal. You are burping the natural working space 
out of the natural layout.

Since COW implies mandatory movement of data, every time you burp out 
all the slack and pack all the data together you are taking your 
regularly modified files and moving them far, far away from the places 
where frequently modified files are most happy (e.g. the 
only-partly-full data region they were just living in).

Similarly two files that usually get modified at the same time (say a 
databse file and its rollback log) will tend to end up in the same 
active data extent as time goes on, and if balance decides it can "clean 
up" that extent it will likely give those two files a data-extent 
divorce and force them to the opposite ends of dataland.

COW systems are inherently somewhat chaotic. If you fight that too 
aggressively you will, at best, be wasting the maintenance time.

It may be a decrease in performance measured in very small quanta, but 
so is the expected benefit of most maintenance.


 From the wiki::

https://btrfs.wiki.kernel.org/index.php/FAQ#What_does_.22balance.22_do.3F

btrfs filesystem balance is an operation which simply takes all of the 
data and metadata on the filesystem, and re-writes it in a different 
place on the disks, passing it through the allocator algorithm on the 
way. It was originally designed for multi-device filesystems, to spread 
data more evenly across the devices (i.e. to "balance" their usage). 
This is particularly useful when adding new devices to a nearly-full 
filesystem.
Due to the way that balance works, it also has some useful side-effects:
If there is a lot of allocated but unused data or metadata chunks, a 
balance may reclaim some of that allocated space. This is the main 
reason for running a balance on a single-device filesystem.
On a filesystem with damaged replication (e.g. a RAID-1 FS with a dead 
and removed disk), it will force the FS to rebuild the missing copy of 
the data on one of the currently active devices, restoring the RAID-1 
capability of the filesystem.