On 28.07.2011 16:44, Jan Schubert wrote:

Jan Schubert <Jan.Schubert <at> GMX.li> writes:

quoted

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