On Fri, Sep 16, 2016 at 02:23:44PM -0600, Chris Murphy wrote: > Not a mess, I think it's a good bug report. I think Qu and David know > more about the latest iteration of the convert code. If you can wait > until next week at least to see if they have questions that'd be best. > If you need to get access to the computer sooner than later I suggest > btrfs-image -c9 -t4 -s to make a filename sanitized copy of the > filesystem metadata for them to look at, just in case. They might be > able to figure out the problem just from the stack trace, but better > to have the image before blowing away the file system, just in case > they want it.
I can hang on to the system in its current state, I don't particularly need this machine fully operational. Just to be proactive, I ran the btrfs-image as follows: btrfs-image -c9 -t4 -s -w /dev/sda2 dumpfile http://phead.us/tmp/sgreenslade_home_sanitized_2016-09-16.btrfs In the mean time, is there any way to make the kernel more verbose about btrfs errors? It would be nice to see, for example, what was in the transaction that failed, or at least what files / metadata it was touching. --Sean -- 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
