Re: btrfs_log2phys: cannot lookup extent mapping

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

David Hanke posted on Tue, 20 Dec 2016 09:52:25 -0600 as excerpted:

> I've been using a btrfs-based volume for backups, but lately the
> system's been filling the syslog with errors like "btrfs_log2phys:
> cannot lookup extent mapping for 7129125486592" at the rate of hundreds
> per second. (Please see output below for more details.) Despite the
> errors, the files I've looked at appear to be written and read
> successfully.
> 
> I'm wondering if the contents of the volume are trustworthy and whether
> this problem is resolvable without backing up, erasing and starting
> over?
> 
> Thank you!
> 
> David
> 
> 
> # uname -a
> Linux backup2 3.0.101.RNx86_64.3 #1 SMP Wed Apr 1 16:02:14 PDT 2015
> x86_64 GNU/Linux
> 
> # btrfs --version
> Btrfs v3.17.3

FWIW...

[TL;DR: see the four bottom line choices, at the bottom.]

This is the upstream btrfs development and discussion list for a 
filesystem that's still stabilizing (that is, not fully stable and 
mature) and that remains under heavy development and bug fixing.  As 
such, list focus is heavily forward looking, with an extremely strong 
recommendation to use current kernels (and to a lessor extent btrfs 
userspace) if you're going to be running btrfs, as these have all the 
latest bugfixes.

Put a different way, the general view and strong recommendation of the 
list is that because btrfs is still under heavy development, with bug 
fixes, some more major than others, every kernel cycle, while we 
recognize that choosing to run old and stale^H^Hble kernels and userspace 
is a legitimate choice on its own, that choice of stability over support 
for the latest and greatest, is viewed as incompatible with choosing to 
run a still under heavy development filesystem.  Choosing one OR the 
other is strongly recommended.

For list purposes, we recommend and best support the last two kernel 
release series in two tracks, LTS/long-term-stable, or current release 
track.  On the LTS track, that's the LTS 4.4 and 4.1 series.  On the 
current track, 4.9 is the latest release, so 4.9 and 4.8 are best 
supported.

Meanwhile, it's worth keeping in mind that the experimental label and 
accompanying extremely strong "eat your babies" level warnings weren't 
peeled off until IIRC 3.12 or so, meaning anything before that is not 
only ancient history in list terms, but also still labeled as "eat your 
babies" level experimental.  Why anyone choosing to run an ancient eat-
your-babies level experimental version of a filesystem that's now rather 
more stable and mature, tho not yet fully stabilized, is beyond me.  If 
they're interested in newer filesystems, running newer and less buggy 
versions is reasonable; if they're interested in years-stale level of 
stability, then running such filesystems, especially when still labeled 
eat-your-babies level experimental back then, seems an extremely odd 
choice indeed.

Of course, on-list we do recognize that various distros did and do offer 
support at some level for older than list-recommended version btrfs, in 
part because they backport fixes from newer versions.  However, because 
we're forward development focused we don't track what patches these 
distros may or may not have backported and thus aren't in a good position 
to provide good support for them.  Instead, users choosing to use such 
kernels are generally asked to choose between upgrading to something 
reasonably supportable on-list if they wish to go that route, or referred 
back to their distros for the support they're in a far better position to 
offer, since they know what they've backported and what they haven't, 
while we don't.

As for btrfs userspace, the way btrfs works, during normal runtime, 
userspace primarily calls the kernel to do the real work, so userspace 
version isn't as big a deal unless you're trying to use a feature only 
supported by newer versions, except that if it's /too/ old, the impedance 
mismatch between the commands as they were then and the commands in 
current versions makes support rather more difficult.  However, once 
there's a problem, then the age of userspace code becomes more vital, as 
then it's actually the userspace code doing the work, and only newer 
versions of btrfs check and btrfs restore, for instance, can detect and 
fix problems where code has only recently been added to do so.

In general, then, with btrfs-progs releases and versioning synced to that 
of the kernel, a reasonable rule of thumb is to run userspace of a 
similar version to your kernel, tho unless you're experiencing problems, 
getting a version or two behind on your userspace isn't a big deal.  That 
way, userspace command formats and output will be close enough to current 
for easier support, and if there's a fix for a specific problem you've 
posted in newer userspace, the problem and fix are still fresh enough in 
people's minds that someone will probably recognize it and point out that 
a newer version can handle that, and you can worry about upgrading to the 
latest and greatest at that point.

So bottom line, you have four choices:

1) Upgrade to something reasonably current to get better on-list support.

This would be LTS kernels 4.4 preferred, or 4.1, acceptable, or current 
kernels 4.9 or 4.8, and similarly versioned userspace, so no older than 
btrfs-progs 4.0.

2) Choose to stay with your distro's versions and get support from them.

Particularly if you are already paying for that support, might as well 
use it.

3) Recognize the fundamental incompatibility between wanting to run old 
and stale/stable for the stability it is supposed to offer, and wanting 
to run a still under heavy development not fully stable and mature 
filesystem like btrfs, and either switch to a more stable and mature 
filesystem that better meets your needs for those qualities, or upgrade 
to a distro or distro version that better meets your needs for current 
software better supported by current upstreams like this btrfs list.

4) Stay with what you have, and muddle through as best you can.

After all, it's not like we /refuse/ to offer support to btrfs that old, 
if we recognize a problem that we know can be fixed by code that old 
we'll still tell you, and if we know there's a fix in newer versions 
we'll still tell you and try to point you at the appropriate patch for 
you to apply to your old version if possible, but we simply recognize 
that for something that old, our support will be rather limited, at best.

But it remains your system and your data, so your choice, even if it's 
against everything we normally recommend.


Finally, a personal disclosure.  I'm a btrfs user and list regular, not a 
dev.  As such, my own answers will rarely get code-level technical or 
point to specific patches, but because I /am/ a regular, I can still 
answer the stuff that comes up regularly, leaving the real devs and more 
expert replies to cover detailed content that's beyond me.  So while it's 
quite possible someone else will recognize a specific bug and be able to 
point you toward a specific fix, tho honestly I don't expect it for 
something as old as what you're posting about, general list-recommended 
upgrades and alternatives for people posting with positively ancient 
versions is squarely within my reply territory. =:^)

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