> How do you know it's a bad superblock? While I'm not a dev just a list > regular, show-super looks reasonable from here, and find-root does find > what appears to be a good root. From here the problem seems to be a bad > ctree (of several), not a bad superblock. yes i think you're right. i think that was just the initial thinking of #btrfs > > First thing to try is mounting with nospace_cache. If that works, try > mounting with clear_cache and letting it work for a bit to rebuild. nope, same error. > > If that doesn't work, it may simply be the log tree. btrfs-zero-log is > used to fix that, but before you try that, read this entry in the FAQ > and follow the instructions for making a filesystem image to turn in to > the devs to help them fix such problems, and consider making a backup > of the damaged filesystem using dd/ddrescue, since the warning about > making it possibly more difficult to recover if this is NOT the problem > applies: tried this, btrfs-image complains about roughly the same error, btrfs-zero-log said the following: http://bpaste.net/show/328495 > Another thing to try is mounting recovery,ro. A number of people have > reported that would work when simple recovery wouldn't, because when > it was writable btrfs would immediately try to fix the problem and > immediately fail. nope, same error. here's what happens when i run fsck http://cwillu.com:8080/74.84.235.22/3 "Critical roots corrupted, unable to fsck the FS" sounds like especially good news ;p -- Shaun Reich, KDE Software Developer (kde.org) -- 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
