On Sep 21, 2014, at 4:57 AM, Jakob Breier <Jakob.Breier@xxxxxxxxxxxxxx> wrote: > > I've tried opening a few files and they appear to be fine. I'll take a more thorough look later. I'm not sure what to expect with --init-extent-tree after the fact. It might have holes in it (?) seeing as I'm not sure how we get something whole from something that had holes in it, that otherwise couldn't be fixed any other way. So I'd take it with a grain of salt unless someone else says it should be fine. I'm vaguely remembering something about --init-extent-tree discussed in archives, but can't find it, about maybe it should come with a more dire warning, and that the user would probably want to create a new filesystem after retrieving their data from a fixed file system. I know --init-csum-tree removes all csums, so everything produces checksum errors. You might want to check for hardware related sources for this corruption though. I don't recall if there was any kind of crash that instigated all of this? Do a 'smartctl -t long' test and also a badblocks -swv (destructive write/read with progress) and see if this turns up any problems with device. Check dmesg after badblocks to see if there are any drive or controller related messages, esp link resets or read or write errors. Last it might be worth a memtest86+ overnight or even better over a weekend. Something caused this corruption, even on crashes I've not had much worse than orphans needing to be cleaned up on the next boot. 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
