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

[Tomasz Chmielewski <tch@virtall.com>]

On 2014-12-13 10:39, Robert White wrote:

> 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.

There were several reasons for running balance on this system:

1) I was getting "no space left", even though there were hundreds of GBs 
left. Not sure if this still applies to the current kernels (3.18 and 
later) though, but it was certainly the problem in the past.

2) The system was regularly freezing, I'd say once a week was a norm. 
Sometimes I was getting btrfs traces logged in syslog.
After a few freezes the fs was getting corrupted to different degree. At 
some point, it was so bad that it was only possible to use it read only. 
So I had to get the data off, reformat, copy back... It would start 
crashing after a few weeks of usage.

My usage case is quite simple:

- skinny extents, extended inode refs
- mount compress-force=zlib
- rsync many remote data sources (-a -H --inplace --partial) + snapshot
- around 500 snapshots in total, from 20 or so subvolumes

Especially rsync's --inplace option combined with many snapshots and 
large fragmentation was deadly for btrfs - I was seeing system freezes 
right when rsyncing a highly fragmented, large file.

Then, running balance on the "corrupted" filesystem was more an exercise 
(if scrub passes fine, I would expect balance to pass as well). Some 
BUGs it was causing was sometimes fixed in newer kernels, sometimes not 
(btrfsck was not really usable a few months back).

3) I had different luck with recovering btrfs after a failed drive (in 
RAID-1). Sometimes it worked as expected, sometimes, the fs was getting 
broken so much I had to rsync data off it and format from scratch (where 
mdraid would kick the drive after getting write errors - it's not the 
case with btrfs, and weird things can happen).
Sometimes, running "btrfs device delete missing" (it's balance in 
principle, I think) would take weeks, during which a second drive could 
easily die.
Again, running balance would be more exercise there, to see if the newer 
kernel still crashes.


> 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?

For me - it's a good test to see if btrfs is finally getting stable 
(some cases explained above).


> 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".

Fragmentation was an issue for btrfs, at least a few kernels back (as 
explained above, with rsync's --inplace).
However, I'm not running autodefrag anywhere - not sure how it affects 
snapshots.


> 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".

For me, it was passing fine, where balance was crashing the kernel.


Again, my main rationale for running balance is to see if btrfs is 
behaving stable. While I have systems with btrfs which are running fine 
for months, I also have ones which will crash after 1-2 weeks (once the 
system grows in size / complexity).

So hopefully, btrfsck had fixed that fs - once it is running stable for 
a week or two, I might be brave to re-enable btrfs quotas (was another 
system freezer, at least a few kernels back).


-- 
Tomasz Chmielewski
http://www.sslrack.com