On Jun 23, 2014, at 11:49 PM, Mike Hartman <m...@hartmanipulation.com> wrote:
>>> I zeroed out the drive and ran every smartctl test on it I could find >>> and it never threw any more errors. >> >> Zeroing SSDs isn't a good way to do it. Use ATA Secure Erase instead. The >> drive is overprovisioned, so there are pages without LBAs assigned, which >> means they can't be written to by software. Plus "zeros" make SSD pages full >> of zeros, rather than being empty and ready to be written to. ATA Secure >> Erase is supposed to make them empty (write ready) and does it for all pages. >> >> http://mackonsti.wordpress.com/2011/11/22/ssd-secure-erase-ata-command/ > > Thanks, that's good information to have. I'll definitely do that next time. > > So, setting aside potential issues with the drive itself... Anything > else you can recommend in regards to accessing the data in my image? I have no ideas. > If I can't repair/rebuild the whole file system I can live with that, > but at the very least I have some specific files I'd like to salvage. https://btrfs.wiki.kernel.org/index.php/Restore Your superblocks are good according to btrfs rescue super-recover. And various tree roots are found by btrfs-find-root including a tree root that also matches the latest latest generation: • Super think's the tree root is at 763420672, chunk root 20971520 • Found tree root at 763420672 gen 214454 level 1 And yet btrfs restore fails. I'm not sure why but try: btrfs restore -t 763420672 /dev/mapper/sda6_crypt /media/mint/usb_data/sda6_btrfs_recovery/ If that command doesn't quickly fail or spit out a bunch of messages, then it's probably restoring files. If you confirm in another shell that it is restoring, cancel the restore, and then figure out how to use the --path-regex option with the above command to just get the files you're looking for. If it fails, consider -i to ignore errors. Hopefully any errors stopping restore won't apply to the files you're looking for. If this still fails, then go back up one generation in your btrfs-find-root list and use that tree root: btrfs restore -t 762122240 -i --path-regex '<blah>' /dev/mapper/sda6_crypt /media/mint/usb_data/sda6_btrfs_recovery/ And so on up the list. Maybe one of them will work (?). > Even if the metadata got garbled somehow, the actual data should still > be buried in there somewhere, right? Yeah but without the metadata you don't know where the data is or how to put its extents back together again if it's in multiple extents. Any file with portions being changed will have fragments on a COW file system. And while I don't know what happened or what's corrupt it's possible some tiny bit of really critical metadata is toast and that prevents locating other metadata needed to locate data. > Are any forensic tools up to the > task of finding it? Or is their operation so entwined with the details > of the file system that they wouldn't do me any good? I think you're in #btrfs channel on freenode territory. Try the above, and if all fail, head to #btrfs. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
