Am Donnerstag, 9. Oktober 2014, 21:58:53 schrieben Sie: > > * btrfs-zero-log > > "remove the log tree if log tree is corrupt" > > * btrfs rescue > > "Recover a damaged btrfs filesystem" > > chunk-recover > > super-recover > > How does this relate to btrfs check? > > * btrfs check > > "repair a btrfs filesystem" > > --repair > > --init-csum-tree > > --init-extent-tree > > How does this relate to btrfs rescue? > > These three translate into eight combinations of repairs, adding -o recovery > there are 9 combinations. I think this is the main source of confusion, > there are just too many options, but also it's completely non-obvious which > one to use in which situation. > > My expectation is that eventually these get consolidated into just check and > check --repair. As the repair code matures, it'd go into kernel > autorecovery code. That's a guess on my part, but it's consistent with > design goals.
Also I think these should at least all be unter the btrfs command. So include btrfs-zero-log in btrfs command. And well how about "btrfs repair" or "btrfs check" as upper category and at least add the various options as commands below it? So there is at least one command and one place in manpage to learn about the various options. But maybe some can be made automatic as well. Or folded into btrfs check -- repair. Ideally it would auto-detect which path to take on filesystem recovery. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
