Pedro Fonseca
2013-Nov-20 15:22 UTC
Btrfsck complains about "fs tree 264 refs 1 not found"
Hi, I''ve been getting the error message "fs tree 264 refs 1 not found" when running btrfsck (v0.19) after a test case. The test case creates and then deletes a subvolume while concurrently creating a snapshot of the parent directory. This situation occurred with kernel version 3.11.1. Here''s one of the interleavings that triggers the "not found" message:> CPU: 0 Op: write > CPU: 1 Op: btrfs_subvol_delete ("d16", fail) > CPU: 1 Op: write > CPU: 1 Op: btrfs_subvol_create ("d16/d13b", success) > CPU: 0 Op: btrfs_subvol_snapshot ("d16" to > "d16/d21/d6d/d74/d101/d13d", success) > CPU: 1 Op: link > CPU: 1 Op: creat > CPU: 1 Op: btrfs_subvol_delete ("d16/d13b", success) > CPU: 1 Op: read > CPU: 0 Op: dread > CPU: 0 Op: creatAnother example that also triggered the message:> CPU: 0 Op: dread > CPU: 0 Op: write > CPU: 0 Op: btrfs_subvol_snapshot ("d16" to > "d16/d21/d6d/d74/d101/d13d", success) > CPU: 1 Op: btrfs_subvol_delete ("d16", fail) > CPU: 1 Op: write > CPU: 1 Op: btrfs_subvol_create ("d16/d13b", success) > CPU: 0 Op: dread > CPU: 0 Op: creat > CPU: 1 Op: link > CPU: 1 Op: creat > CPU: 1 Op: btrfs_subvol_delete ("d16/d13b", success) > CPU: 1 Op: readIn this case, "btrfs_subvol_snapshot" overlapped with the "btrfs_subvol_create" operation but it did not overlap with the second "btrfs_subvol_delete". Btrfsck output (after unmounting the FS):> fs tree 257 refs 5 > unresolved ref root 258 dir 256 index 10 namelen 3 name d21 > error 600 > unresolved ref root 262 dir 256 index 10 namelen 3 name d21 > error 600 > unresolved ref root 263 dir 256 index 10 namelen 3 name d21 > error 600 > unresolved ref root 265 dir 256 index 10 namelen 3 name d21 > error 600 > fs tree 262 refs 3 > unresolved ref root 263 dir 256 index 39 namelen 3 name da6 > error 600 > unresolved ref root 265 dir 256 index 39 namelen 3 name da6 > error 600 > fs tree 263 refs 2 > unresolved ref root 265 dir 256 index 43 namelen 3 name dce > error 600 > fs tree 264 refs 1 not found > unresolved ref root 265 dir 256 index 56 namelen 4 name d13b > error 600 > found 9924608 bytes used err is 1 > total csum bytes: 9208 > total tree bytes: 495616 > total fs tree bytes: 417792 > btree space waste bytes: 153475 > file data blocks allocated: 12365824 > referenced 11440128 > btrfsck: Btrfs Btrfs v0.19Let me know if you need more information. Pedro -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pedro Fonseca posted on Wed, 20 Nov 2013 16:22:18 +0100 as excerpted:> I''ve been getting the error message "fs tree 264 refs 1 not found" when > running btrfsck (v0.19) after a test case. The test case creates and > then deletes a subvolume while concurrently creating a snapshot of the > parent directory. This situation occurred with kernel version 3.11.1.Well, at least you''re running a reasonably current kernel (tho 3.12 is out and IIRC it was 3.11.5 that contained some critical btrfs patches that 3.11.1 is missing), but quoting the wiki FAQ on btrfs 0.19: https://btrfs.wiki.kernel.org/index.php/FAQ#I.27m_running_btrfs_0.19...>>>>I''m running btrfs 0.19... This is, unfortunately, almost meaningless. Almost all of the "interesting" code in btrfs is in the kernel, so the main thing you should be reporting is the version of the kernel you''re running. Even if you want to report a problem with the btrfs userspace tools, the main version number (which is usually 0.19) is useless, because it hasn''t been updated in at least 18 months. If you have installed from your distribution''s package manager, then the version number of the package will usually include a date that will indicate when your btrfs tools were compiled; it is this package version that you should tell people about if you have a problem. If you have built your btrfs-progs tools from git, please tell us what git commit ID was the head when you built your tools. A recent version of the btrfs-progs tools should report the commit ID as part of the version number when you run them: hrm@ruthven:~ $ btrfs --help Usage: [...] Btrfs v0.19-116-g13eced9 ^^^^^^^^ this is the git commit ID <<<< Further, quoting the getting started page: https://btrfs.wiki.kernel.org/index.php/Getting_started>>>>btrfs is a fast-moving target. There are typically a great many bug fixes and enhancements between one kernel release and the next. Therefore: If you have btrfs filesystems, run the latest kernel. If you are running a kernel two or more versions behind the latest one available from kernel.org, the first thing you will be asked to when you report a problem is to upgrade to the latest kernel. Some distributions keep backports of recent kernels to earlier releases -- see the page below for details. Having the latest user-space tools are also useful, as they contain additional features and tools which may be of use in debugging or recovering your filesystem if something goes wrong. Note also that btrfs is still considered experimental. While many people use it reliably, there are still problems being found. You should keep and test backups of your data, and be prepared to use them. <<<< FWIW, my btrfs-progs version built from git a few days ago: Btrfs v0.20-rc1-596-ge9ac73b Basically, btrfs-progs development happens in branches, with branches pulled to master only when they''re considered ready, so master branch head is considered the reference for btrfs testing. If you''re behind that and can''t name a specific bug regression as your reason, you''re behind. And as I said, kernel 3.11.1 is not only behind in general (tho still within the two releases guideline above so it''s not /horribly/ behind yet), it''s known to be lacking a couple critical patches found in 3.12 and later 3.11.x stable series. So testing is good, but please update to current and see if the problem remains. =:^) -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html