From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [195.159.176.226] ([195.159.176.226]:48391 "EHLO blaine.gmane.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S932479AbcLTXZM (ORCPT ); Tue, 20 Dec 2016 18:25:12 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cJTmE-0002Pv-Rn for linux-btrfs@vger.kernel.org; Wed, 21 Dec 2016 00:24:58 +0100 To: linux-btrfs@vger.kernel.org From: Duncan <1i5t5.duncan@cox.net> Subject: Re: btrfs_log2phys: cannot lookup extent mapping Date: Tue, 20 Dec 2016 23:24:47 +0000 (UTC) Message-ID: References: <89be6fee-5b18-7a9d-11ea-85abeab28022@ece.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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