Re: btrfs cleaner failure - fs/btrfs/extent-tree.c:5748 (3.14.0)

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

Hugo Mills posted on Sat, 10 May 2014 02:09:02 +0100 as excerpted:

> Life would be so much easier if filesystems didn't store any
> persistent state... :)
> 
> The number of people who don't quite get that that's the function
> and natural behaviour of a filesystem is... surprising.
> 
> As in, "Your filesystem got corruption as a result of a bug in some
> earlier version. Upgrading to the new version isn't magically going to
> make that corruption go away". (Not saying that's what's happened here,
> but it's common, and commonly misunderstood).

FWIW, this is why I'm currently doing a mkfs.btrfs and copying over from 
primary backup (an identically sized partition on the same set of 
physical devices, also btrfs, secondary backup is reiserfs on a different 
device, just in case) every few kernel cycles, perhaps twice a year or 
every eight months.

My thinking is that even if scrub/balance/btrfs-check report no problems:

a) There are new on-device filesystem features I can now take advantage 
of (at least, there have been in each of the two mkfs.btrfs cycles I've 
done so far).  And...

b) Recreating the filesystem and copying everything over new limits the 
time-window I'm exposed to old and potentially latent bugs that may have 
in fact been fixed in new deployments without every having triggered at 
the time, due to masking from some other bug or happenstance that may 
eventually go away, otherwise leaving me exposed to this strange corner-
case bug from two years or whatever ago.

I'll probably continue to do that until btrfs is considered stable, or 
even past that (tho then likely at a rather lower frequency, say every 
year to year and a half), because it's relatively easy to do with the way 
I handle backups.

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