Martin posted on Sun, 29 Sep 2013 03:10:37 +0100 as excerpted: > So... > > Any options for btrfsck to fix things? > > Or is anything/everything that is fixable automatically fixed on the > next mount? > > Or should: > > btrfs scrub /dev/sdX > > be run first? > > Or? > > > What does btrfs do (or can do) for recovery?
Here's a general-case answer (courtesy gmane) to the order in which to try recovery question, that Hugo posted a few weeks ago: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/27999 Note that in specific cases someone who knew what they were doing could omit some steps and focus on others, but I'm not at that level of "know what I'm doing", so... Scrub... would go before this, if it's useful. But scrub depends on a second, valid copy being available in ordered to fix the bad-checksum one. On a single device btrfs, btrfs defaults to DUP metadata (unless it's SSD), so you may have a second copy for that, but you won't have a second copy of the data. This is a very strong reason to go btrfs raid1 mode (for both data and metadata) if you can, because that gives you a second copy of everything, thereby actually making use of btrfs' checksum and scrub ability. (Unfortunately, there is as yet no way to do N-way mirroring, there's only the second copy not a third, no matter how many devices you have in that "raid1".) Finally, if you mentioned your kernel (and btrfs-tools) version(s) I missed it, but [boilerplate recommendation, stressed repeatedly both in the wiki and on-list] btrfs being still labeled experimental and under serious development, there's still lots of bugs fixed every kernel release. So as Chris Murphy said, if you're not on 3.11-stable or 3.12- rcX already, get there. Not only can the safety of your data depend on it, but by choosing to run experimental we're all testers, and our reports if something does go wrong will be far more usable if we're on a current kernel. Similarly, btrfs-tools 0.20-rc1 is already somewhat old; you really should be on a git-snapshot beyond that. (The master branch is kept stable, work is done in other branches and only merged to master when it's considered suitably stable, so a recently updated btrfs-tools master HEAD is at least in theory always the best possible version you can be running. If that's ever NOT the case, then testers need to be reporting that ASAP so it can be fixed, too.) Back to the kernel, it's worth noting that 3.12-rcX includes an option that turns off most btrfs bugons by default. Unless you're a btrfs developer (which it doesn't sound like you are), you'll want to activate that (turning off the bugons), as they're not helpful for ordinary users and just force unnecessary reboots when something minor and otherwise immediately recoverable goes wrong. That's just one of the latest fixes. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
