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