Re: 4.2.6: livelock in recovery (free_reloc_roots)?

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

Lukas Pirl posted on Sat, 21 Nov 2015 13:37:37 +1300 as excerpted:

> Can "btrfs_recover_relocation" prevented from being run? I would not
> mind losing a few recent writes (what was a balance) but instead going
> rw again, so I can restart a balance.

I'm not familiar with that thread name (I run multiple small btrfs on 
ssds, so scrub, balance, etc, take only a few minutes at most), but if 
it's the balance thread, then yes, there's a mount option that cancels a 
running balance.  See the wiki page covering mount options.

> From what I have read, btrfs-zero-log would not help in this case (?) so
> I did not run it so far.

Correct.  Btrfs is atomic at commit time, so doesn't need a journal in 
the sense of older filesystems like reiserfs, jfs and ext3/4.

What's this log, then?  While btrfs won't fully write normal file writes 
until a commit (every 30 seconds by default, there's a mount option...), 
which is atomic (with copy-on-write helping here) so in the event of a 
crash either the before or after state is returned, not something half 
written, fsync is different.  That says don't return until the file is 
written to storage.  But if a commit is done to ensure that, there may be 
far more data to commit that otherwise doesn't need to be committed yet, 
seriously slowing things down.  So that's where this log comes in.  It's 
purely a log of fsynced data (and perhaps a few other similar things, I'm 
not a dev and am not sure) between atomic commits, so the fsync can 
return quickly while still having actually written the data to store, 
without having to wait upto 30 seconds (by default) for the normal commit 
to complete, or forcing a commit, along with everything else half 
written, early.

There was a bug at one point where this log could be corrupted and thus 
couldn't be written properly at mount, but the primary trigger bug for 
that problem is long since fixed, so while there's various hardware bugs 
and etc that could still by remote chance cause problems, thus the option 
to zero the log, it's a very rare occurrence, and the trace when it fails 
is telltale enough that if it's posted the devs can tell you to run the 
zero-log command then.  Otherwise, it generally does no good, and while 
it generally does no serious harm beyond the loss of a few seconds worth 
of fsyncs, etc, either, because the commits /are/ atomic and zeroing the 
log simply returns the system to the state of such a commit, it's not 
recommended as it /does/ needlessly kill the log of those last few 
seconds of fsyncs.

> By the way, I can confirm the defect of 'btrfs device remove missing …"
> mentioned here: http://www.spinics.net/lists/linux-btrfs/msg48383.html :
> 
> $ btrfs device delete missing
> /mnt/data ERROR: missing is not a block device
> $ btrfs device delete 5
> /mnt/data ERROR: 5 is not a block device

That's a known bug, with patches working their way thru the system both 
to provide a different alternative and to let btrfs device delete missing 
work again, but IDR the specific status of those patches.  Presumably 
they'll be in 4.4, but I don't know if they made it into 4.3 or not and 
don't feel like looking it up ATM when you could do so just as easily.

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