Kernel-3.1 Crash

Mike Snitzer snitzer at redhat.com
Fri Oct 28 15:33:16 UTC 2011


On Fri, Oct 28 2011 at 11:11am -0400,
Antonio Trande <anto.trande at gmail.com> wrote:

> >You said that you saw the problem with Linux 3.0 too though?  But only
> >if fsck is enabled.. yet btrfs doesn't yet have a publicly available
> >fsck... so you need to clarify your 3.0 comment earlier.
> 
> It's only my doubt.
> Only one time i've tried to enable fsck on btrfs in fstab with Kernel 3.0
> and seems to get same problem (but i'm not certain).

again there is no fsck for btrfs yet.  so this doesn't make sense.

> >That aside, I'd imagine that anaconda unnecessarily introduced a
> >multipath layer for your storage when you really don't have multiple
> >paths.  What does 'multipath -ll' show?
> 
> # multipath -ll
> mpatha (350014ee25794e366) dm-0 ATA,WDC WD5000BEVT-2
> size=466G features='0' hwhandler='0' wp=rw
> `-+- policy='round-robin 0' prio=1 status=active
>   `- 0:0:0:0 sda 8:0  active ready running

Yeah, anaconda should _not_ have introduced multipath for your setup.
It is a layer of complexity that you are not benefitting from (worse: it
is somehow causing instability for you with your btrfs config).

It is possible to rebuild your initramfs (using dracut) so it does _not_
have multipath enabled.

I think the easiest would be to simply uninstall the
'device-mapper-multipath' package and make sure /etc/multipath/ and
/etc/multipath.conf no longer exists.

So when you re-create the initramfs with dracut it won't be able to copy
any multipath enabling bits into the initramfs.

Mike


More information about the kernel mailing list