Jerome Haynes-Smith posted on Thu, 03 Oct 2013 18:28:51 +0100 as excerpted:
> Hi folks > > I am using btrfs in openSUSE 12.3 and I have seen several of these > recently: > > 2013-10-03 10:04:27] ------------[ cut here ]------------ > [2013-10-03 10:04:27] WARNING: at > /home/abuild/rpmbuild/BUILD/kernel-desktop-3.7.10/linux-3.7/fs/btrfs/ extent_map.c:258 > unpin_extent_cache+0x65/0x140 [btrfs]() While I'm not a dev, just a list regular and btrfs user myself... The BIG thing I notice here is that kernel version. Both here on the list and on the btrfs wiki ( https://btrfs.wiki.kernel.org ), running a current kernel is REPEATEDLY stressed. Btrfs is still under development and every kernel series there are bug fixes that you don't have if you're running an old kernel. Running AT LEAST the second latest stable kernel series is EXTREMELY STRONGLY RECOMMENDED, with latest stable RECOMMENDED, and latest development kernel or even the btrfs-next patches also options. If you're running older than that, you're both missing fixes that could prevent problems, and as a tester of still under development btrfs, the reports for problems you do have and report will be less useful, since you're so far behind current code. Current dev kernel is 3.12 series, with 3.12-rc3 out now. That means btrfs testers should be running NO OLDER THAN 3.10, and preferably the latest stable 3.11 if not the 3.12-rcs or btrfs-next. (Tho due to some crossed signals 3.11.4 stable doesn't have the queued btrfs-stable patches, but 3.11.5 should, see earlier list threads. Of course queued for stable means corresponding commits are already in dev, so 3.12 has those fixes already.) That log says kernel 3.7, which is **OLD**, at least for btrfs testing purposes. People do have reasons not to run the latest kernel, but running an older kernel is really at odds with the whole idea of being a tester for a kernel system like btrfs that's still under development, so choosing one or the other would be wise. FWIW, personally I run the current dev-kernel built direct from git, but don't switch to a new kernel until after rc2 or so, when any real system- killer issues should be fixed or at least warned about for those following kernel development, but it's still early enough in the cycle to get any bugs I find and report fixed before general 3.x.0 release. As it happens I built my first 3.12 series kernel right at 3.12-rc2 and am actually still running it as I haven't pulled and rebuilt since, tho rc2 is actually stale now as rc3 is out and I think we're already half way thru the week to rc4. > [2013-10-03 10:04:27] Pid: 22467, comm: btrfs-endio-wri Tainted: G > W O 3.7.10-1.16-desktop #1 That taint is all GPL modules (G, not the P you'd get if you had loaded anything not GPL), but with an out-of-tree modules (O) and a previous warning, probably an earlier instance of what you're posting about... > I see no symptoms of a problem at this time. (Disks seem a bit busy, > but I think that's the snapperd) It's reasonably common knowledge, but just in case... Note that especially if you're taking regular snapshots as the snapperd mention indicates you probably are... check that you're mounting with the noatime option, as atime updates aren't needed on most modern systems (mutt users being a possible exception, since it depends on atimes unless it's configured to use mbox format), and atime updates and COW snapshotting such as btrfs uses "fight with each other", generally needlessly increasing writes and the unique-(meta)data size of each snapshot. (The kernel's current relatime default is compromise between atime legacy compatibility and noatime efficiency, but relatime still updates once a day on access, which if you're keeping daily snapshots for any length of time can still add up rather fast. So while relatime's a good compromise default for ext* filesystems, not so much for btrfs with regular snapshotting.) > I don't seem to find many matches for 'unpin_extent_cache+0x65/0x140 > [btrfs]' which I believe is the actual point that the system decided to > do the 'opps'.. but I may be wrong. > > Is this something I need to do something about ? > I can send a siga output if it will help. (I tried to attach it as a > compressed text file, but the email bounced previously) Yeah, AFAIK the various kernel lists bounce most binary attachments as spam/malware control, and there's a limit on text attachment size. Sending a link to a (preferably non-expiring, so people researching a similar problem later can still get it) pastebin posted somewhere is one common workaround, while sending the big stuff only on request and generally directly to the dev requesting it, for special cases that need detail debugging, is another. I'd definitely recommend a newer kernel. That may well fix the problem right there. And your btrfs-tools package should be similarly current; anything 0.19 era is OLD, with current git (as of a few days ago anyway) being (IIRC) 358 commits beyond 0.20-rc1. If you're still seeing those warnings with something current /then/ you can investigate further, but I'm guessing you won't, as IIRC at least one fix since 3.7 has been related to unpin bugs. -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html