Jan Schmidt <list.btrfs@xxxxxxxxxxxxx> writes: > On 27.03.2012 18:24, cwillu wrote: >> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth <cwg@xxxxxxxx> wrote: >>> A scrub done the morning after the incident also didn't find any >>> problems: >>> >>> root@mim:/home/cwg# btrfs scrub status / >>> scrub status for 2da00153-f9ea-4d6c-a6cc-10c913d22686 >>> scrub started at Tue Mar 27 10:37:49 2012 and finished after 3921 seconds >>> total bytes scrubbed: 550.20GB with 0 errors >> >> If btrfs is able to find a good copy, it will fix the bad copy automatically. > > It does mention this in your logs, though. Grep for "repair", if it > doesn't occur, btrfs didn't repair any failures. "repair" doesn't occur in the logs. Actually, there are no other entries from btrfs. So why didn't btrfs try to repair a block it believed to be bad? -- 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
