[...] > Ca I get a strong confirmation that I should run with the “—repair” option on each device? Thanks. > > Vincent > > > Checking filesystem on /dev/sdk > UUID: 6a742786-070d-4557-9e67-c73b84967bf5 > checking extents [o] > checking free space cache [.] > root 5 inode 1341670 errors 400, nbytes wrong > root 11406 inode 1341670 errors 400, nbytes wrong [...] I just remember that I have seen this kind of error before; luckily, I found the btrfs check output (august 2015) on some backup of an old snapshot; In my case it was on a raid5 fs from november 2013, 7 small txt files (all several 100 bytes) and the 7 errors are repeated for about 10 snapshots. I did # find . -inum <inode number> to find the files. 2 of the 7 were still in the latest/actual subvol and I just recreated them. The errors from the older snapshots are still there as far as I remember from the last btrfs check I did (with kernel 4.3.0 tools 4.3.x). The fs is converted to raid10 since 3 months. As I also got other fake errors (as in this https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg48325.html ), I won't run a repair until I see proof that this 'errors 400, nbytes wrong' is a risk for file-server stability. I just see that on an archive clone fs with this 10 old snapshots (created via send|receive), there is no error. In your case, it is likely just 1 small file in rootvol (5) and the same allocation in other subvol (11406), so maybe you can fix this like I did and don't run a '--repair' -- 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
