On Mon, Feb 25, 2013 at 11:51:02PM -0700, Marc MERLIN wrote: > TL;DR; > WARNING: at fs/btrfs/tree-log.c:1984 walk_down_log_tree+0x51/0x307() > WARNING: at fs/btrfs/tree-log.c:1988 walk_down_log_tree+0x6c/0x307() > kernel BUG at fs/btrfs/volumes.c:3753! > > It's way time for btrfs to stop crashing your system with no recovery flag > that works to clear the log if the log can't be replayed. Hell, on non > development systems, it should just auto discard the log if it can't be > replayed without user input. > > > Details: > It's been almost a year that I'm doing my best to test btrfs and report > bugs, but how quickly it crashes on mount if anything is off, is a huge > usability problem. > > I just again, lost use of my machine today after an unrelated problem caused > a crash/reboot, and incomplete btrfs writes to my device. > That happens, it's life. > > But after that, I get to roll a dice of whether btrfs will recover, or just > crash on mount. > It's slightly more liveable if it's a scratch filesystem on a developer box, > you just don't mount it. > It's really really sucky if it's your root filesystem and you need to boot > from a rescue partition/media to recover each time. > > Then, I spent 3 hours reproducing the crash again, with netconsole working > so that I can get a useful bugreport, which I send here.
So how did you reproduce it? I'll take a fs_image, but being able to reproduce the problem is more valuable. Thanks, -- 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
