Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )

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

Marc MERLIN posted on Wed, 09 Apr 2014 09:51:34 -0700 as excerpted:

> But since we're talking about this, is btrfsck ever supposed to return
> clean on a clean filesystem?

FWIW, it seems to return clean here, on everything I've tried it on.

But I run relatively small partitions (the biggest is I believe 40 gig, 
my media partitions are still reiserfs on spinning rust, while all my 
btrfs partitions are on SSD and most are raid1 both data/metadata, with 
the exceptions (my normal /boot and the backup /boot on the other ssd in 
the pair that's btrfs raid1 for most partitions) being tiny mixed-data/
metadata dup), and keep them pretty clean, running balance and scrub when 
needed.

I had seen some scrub recoveries back when I was doing suspend-to-ram and 
the system wasn't reliably resuming, I've quit doing that and recently 
did a new mkfs.btrfs and restored from backup on the affected filesystems 
in ordered to take advantage of newer features like 16k metadata nodes, 
so in fact have never personally seen an unclean output of any type from 
btrfs check.

Tho I don't run btrfs check regularly as in normal mode it's read-only 
anyway, and I know it can make some problems worse instead of fixing them 
in repair mode, so my normal idea is why run it and see stuff that might 
make me worried if I can't really do much about it, and I prefer balance 
and scrub instead if there's problems.  But I have run it a few times as 
I was curious just what it /would/ output, and everything came up clean 
on the filesystems I ran it on.

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