[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090201014050.GD24173@disturbed>
Date: Sun, 1 Feb 2009 12:40:50 +1100
From: Dave Chinner <david@...morbit.com>
To: Pavel Machek <pavel@...e.cz>
Cc: Christoph Hellwig <hch@...radead.org>,
Eric Sesterhenn <snakebyte@....de>,
Chris Mason <chris.mason@...cle.com>,
linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org
Subject: Re: Warning and BUG with btrfs and corrupted image
On Mon, Jan 26, 2009 at 05:27:11PM +0100, Pavel Machek wrote:
> On Wed 2009-01-21 15:00:42, Dave Chinner wrote:
> > On Tue, Jan 20, 2009 at 11:20:19PM +0100, Pavel Machek wrote:
> > > On Tue 2009-01-20 08:28:29, Christoph Hellwig wrote:
> > > > I think that was the issue with the debug builds. If you do this
> > > > testing always do it without CONFIG_XFS_DEBUG set as with that option
> > > > we intentionally panic on detected disk corruptions.
> > >
> > > Uhuh, *_DEBUG options are not supposed to make kernel less
> > > stable/robust. Should that crashing functionality be guarded with
> > > command line option or something? ext2 has errors=panic mount
> > > option...
> >
> > No, it's a debugging option that is described as:
> >
> > "Say N unless you are an XFS developer, or you play one on TV."
> >
> > Seriously, if you aren't trying to develop XFS stuff then *don't turn it
> > on*.
>
> What about this, then?
....
> + Turning this option on will result in kernel panicking any time
> + it detects on-disk corruption.
Thin end of a wedge. There's a couple of thousand conditions that
CONFIG_XFS_DEBUG introduces kernel panics on:
$ grep -r ASSERT fs/xfs |wc -l
2095
CONFIG_*_DEBUG means include *debug* code there to help developers,
including adding additional failure tests into the kernel. Besides,
which bit of "don't turn it on unless you are an XFS developer"
don't you understand?
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists