On Fri, Oct 28 2011 at 11:11am -0400, Antonio Trande <anto.trande@xxxxxxxxx> 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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
