# btrfs scrub status /mnt/backup/ scrub status for 97972ab2-02f7-42dd-a23b-d92efbf9d9b5 scrub started at Thu May 1 14:29:57 2014 and finished after 97253 seconds total bytes scrubbed: 1.11TB with 13684 errors error details: read=13684 corrected errors: 2113, uncorrectable errors: 11571, unverified errors: 0 Above is the output from a scrub of a damaged disk. It was formatted with default options (dup for metadata and single for data) so obviously the corrected errors are all for metadata. May 1 18:23:51 server kernel: [14216.461759] BTRFS: i/o error at logical 505396924416 on dev /dev/sde, sector 989216904: metadata leaf (level 0) in tree 823 May 1 18:23:51 server kernel: [14216.461762] BTRFS: i/o error at logical 505396924416 on dev /dev/sde, sector 989216904: metadata leaf (level 0) in tree 823 May 1 18:23:54 server kernel: [14219.704819] BTRFS: i/o error at logical 505398464512 on dev /dev/sde, sector 989219912: metadata leaf (level 0) in tree 823 May 1 18:23:54 server kernel: [14219.704825] BTRFS: i/o error at logical 505398464512 on dev /dev/sde, sector 989219912: metadata leaf (level 0) in tree 823 May 1 18:24:30 server kernel: [14255.174994] BTRFS: i/o error at logical 505614372864 on dev /dev/sde, sector 991738760: metadata leaf (level 0) in tree 2 May 1 18:24:30 server kernel: [14255.174998] BTRFS: i/o error at logical 505614372864 on dev /dev/sde, sector 991738760: metadata leaf (level 0) in tree 2 To discover whether there were any metadata errors I grepped for "metadata" in the kernel message log and found lots of lines like the above. Will all errors that involve metadata match a grep for "metadata" in the kernel message log? I think it would be good to have a scrub count of the number of uncorrectable metadata vs data errors. When there are uncorrectable data errors you know the name of the file (it's in the kernel message log) and can recover just that file. When there are uncorrectable metadata errors you don't. Also would it be possible to log the names of directories that are affected by uncorrectable metadata errors? When BTRFS scales up to the systems where a "find /" takes days to complete and run 24*7 there won't be an option to just restore from backup. In this case the root of every subvol appears undamaged so BTRFS should be able to tell me part of the path related to metadata corruption. # btrfs subvol list /mnt/backup/ ID 823 gen 3212 top level 5 path backup ID 826 gen 1832 top level 5 path backup-2013-05-21 Above is the start of the output of a subvol list, there is no ID 2. What does the "tree 2" in the above kernel error log mean? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- 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