Sonic posted on Mon, 03 Aug 2015 12:32:21 -0400 as excerpted: > Are either one of these called for? > > btrfs check --repair or btrfs check --repair --init-csum-tree > > Seems like they might be a last ditch attempt. Is one preferred over the > other?
The read-only check (without --repair) couldn't read the chunk tree, so check --repair probably should run into the same issue and not be able to do anything as well. check --init-csum-tree reinitializes the checksums, but to do that you have to have something to reinitialize on, so that's unlikely to do anything, either. (I did have that in mind as a possibility after the superblock recovery and chunk-recover operations, tho, if necessary. That's why I mentioned check at the end. But the message was long enough already and that would have been getting ahead of things, so...) > Is: > btrfs rescue chunk-recover a much less dangerous attempt (IOW it wont > hurt to try it first)? I'd not call it less dangerous, but given that the chunk tree can't be read, you're already dealing with dangerous. That's what I'd try here (tho Hugo's suggesting it won't help has me doubting, but that's where things do point from what I see). Which is why I mentioned doing a raw device backup, before attempting it. Chunk-recover is pretty invasive, and if it doesn't work, it could make the filesystem unrecoverable. It's basically a one-shot deal. A raw device backup can be used to avoid it being one-shot, but of course that does require that you have enough devices of sufficient size to backup to, which certainly in the terabyte range, is a potential problem unless you're a big-budget corporate user with a stack of spare devices on hand. I believe Hugo's right on zero-log, tho. That's a fix for a very specific situation, seen most often due to a specific bug that was short lived and has been fixed for quite some time, now, tho in certain very narrow post-crash situations the same fix has been known to work too. There's no evidence you're anywhere near that very specific situation, so zero-log's just not the tool for this job. And it could make things slightly worse, too, tho in theory at least, all you're doing is cutting off the last 30 seconds or so of activity, so the chances of it doing major harm are small, unless you were actively rebalancing or something when the filesystem was last unmounted (gracefully or not). -- 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
