On Sun, Mar 13, 2016 at 11:24 AM, Roman Mamedov <rm@xxxxxxxxxxx> wrote: > > "Blowing away" a 6TB filesystem just because some block randomly went "bad", I'm going to guess it's a metadata block, and the profile is single. Otherwise, if it were data it'd just be a corrupt file and you'd be told which one is affected. And if metadata had more than one copy, then it should recover from the copy. The exact nature of the loss isn't clear, a kernel message for the time of the bad block message might help but I'm going to guess again that it's a 4096 byte missing block of metadata. Depending on what it is, that could be a pretty serious hole for any file system. > I'm running --init-extent-tree right now in a "what if" mode, using > the copy-on-write feature of 'nbd-server' (this way the original block device > is not modified, and all changes are saved in a separate file). So it's a Btrfs on NDB with no replication either from Btrfs or the storage backing it on the server? Off hand I'd say one of them needs redundancy to avoid this very problem, otherwise it's just too easy for even network corruption to cause a problem (NDB or iSCSI). Not related to your problem, I'm not sure whether and how many times Btrfs retries corrupt reads. That is, device returns read command OK (no error), but Btrfs detects corruption. Does it retry? Or immediately fail? For flash and network based Btrfs, it's possible the result is intermittant so it should try again. > It's been > running for a good 8 hours now, with 100% CPU use of btrfsck and very little > disk access. Yeah btrfs check is very much RAM intensive. -- Chris Murphy -- 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
