On 28.07.2011 16:44, Jan Schubert wrote: > Jan Schubert <Jan.Schubert <at> GMX.li> writes: >> OK, Patch 1 to 3 did apply and run successfully on 3.0-git8. I've sent >> Jan some more details about the output of the affected files (which is >> actually just one quite large one). > > Hooray: > > scrub status for 03201fc0-7695-4468-9a10-f61ad79f23ca > scrub started at Thu Jul 28 15:00:54 2011 and finished after 656 seconds > total bytes scrubbed: 143.40GB with 0 errors > > Clean filesystem after deleting the (last) affected file, thx a lot! :-) > Next issue: I have an other filesystem which is also reportet as error free > by scrub: > > scrub status for 62bab779-3a5e-4ad0-8f67-9d727813e7ea > scrub started at Thu Jul 28 16:16:26 2011 and finished after 131 seconds > total bytes scrubbed: 28.91GB with 0 errors > > Doing a btrfsck on the same filesystem I get: > > root 5 inode 5067 errors 400 > root 5 inode 5098 errors 400 > root 5 inode 5123 errors 400 > root 5 inode 5125 errors 400 > root 5 inode 6082 errors 400 > found 30889312256 bytes used err is 1 > total csum bytes: 30113200 > total tree bytes: 51560448 > total fs tree bytes: 8212480 > btree space waste bytes: 11638215 > file data blocks allocated: 30991843328 > referenced 31323025408 > Btrfs v0.19-100-g4964d65 > > Is this something I should be concerned about (regarding the errors)? I think you shouldn't. The "errors 400" is reported constantly in #btrfs, it resolves to REF_ERR_NO_ROOT_BACKREF. There should be a backref, but I haven't heard of any negative impact. If you are curious, you can try to grab the "inspect-internal" patches for btrfs-progs and use "btrfs inspect-internal resolve-inode 5067" to see what files are referenced by those inodes (given you are still running the kernel you used for scrubbing). [... which reminds me I have to send a new version of the btrfs-progs patches since the api changed with v8. damn.] -Jan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
