On Thu, Jun 25, 2015 at 8:08 PM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
> A quite code search leads me to inline extent. > > So, if you still have the original ext* image, > would you please try revert to ext* and then convert it to btrfs again? > > But this time, please convert with --no-inline option, and see if this > remove the problem. Using -n at convert time does not make a difference for the btrfs-convert bugs I've opened: https://bugzilla.kernel.org/show_bug.cgi?id=101191 https://bugzilla.kernel.org/show_bug.cgi?id=101181 https://bugzilla.kernel.org/show_bug.cgi?id=101221 https://bugzilla.kernel.org/show_bug.cgi?id=101231 The last one I just discovered happens much sooner, is easier to reproduce than the other two. It's a scrub right after a successful btrfs-convert that btrfs check says is OK. But the scrub ends with two separate oopses and multiple call traces and a spectacularly hard kernic panic (ssh and even the console dies). So I think btrfs-convert has a bug, but then the kernel code is not gracefully handling it at all either and crashes badly with a scrub; and less badly with balance. However, the file system is still OK despite scrub crash. With balance failure, the file system is too badly damaged and btrfs check and btrfs-image fail. -- Chris Murphy -- 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
