<Slightly off topic> does these bugs exist in systems that converted from ext4 to btrfs using kernel 3.13 and then upgraded to kernel 4.1 ?
On Thu, Jul 9, 2015 at 4:09 AM, Chris Murphy <li...@colorremedies.com> wrote: > 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 -- 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
