On Wed, Feb 04, 2009 at 07:29:51PM +0100, Pavel Machek wrote: > On Sun 2009-02-01 12:40:50, Dave Chinner wrote: > > On Mon, Jan 26, 2009 at 05:27:11PM +0100, Pavel Machek wrote: > > > On Wed 2009-01-21 15:00:42, Dave Chinner wrote: > > > + 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? > > Yes, but DEBUG code is normally to help debugging, not to crash > kernels. Crashing the kernel at exactly the point a problem is detected is often the simplest way of debugging the problem. e.g. CONFIG_VM_DEBUG=y turns on VM_BUG_ON() which crashes the kernel whenever it detects something wrong. Do I turn it on? Yes. Do i complain about it when I hit a VM_BUG_ON()? No, I report the bug and move on. If you turn on a DEBUG option, then you are asking the system to behave in a way useful to a developer, not an end user. That includes panicing when something wrong is detected. > IMO xfs should use errors=panic mount option as ext3 does, > but... We already have an equivalent: /proc/sys/fs/xfs/panic_mask The mask is empty on production kernels and can be selectively turned on (depending on what error type you want to panic on). CONFIG_XFS_DEBUG turns them all on by default so we can, weļl, panic the system and debug any problem that occurs.... Cheers, Dave, -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
